@resouer < The traits I'm familiar with as used in an 0.2.1 ApplicationConfiguration look like this.
See https://github.com/oam-dev/catalog/tree/master/traits/ingresstrait
traits:
- trait:
apiVersion: core.oam.dev/v1alpha2
kind: IngressTrait
metadata:
name: example-ingress-trait
spec:
rules:Note that the content of trait is more or less a full CR including metadata and spec. In the examples I'm seeing for a 0.2.2 Application this isn't the case and I'm just trying to understand the expected behavior. Are you saying that a 0.2.2 platform will take this Application.
apiVersion: core.oam.dev/v1alpha2
kind: Application
metadata:
name: ...
spec:
components:
- name: ...
type: ...
...
traits:
- name: ingress
properties:
rules:
- host: nginx.oam.com
paths:
- path: /and produce a trait instance CR that looks like this?
apiVersion: core.oam.dev/v1alpha2
kind: IngressTrait
metadata:
name: ...
spec:
rules:
- host: nginx.oam.com
paths:
- path: /Specifically that the content of the Application's traits[0]:properties: will be extracted and placed into the trait instance's CR spec:?
If this is the case is it possible to specify metadata within an Application's trait that will be extract and placed into the trait instance CR?
.spec.
In 0.2.1
ApplicationConfiguration it was possible to specify metadata for trait instances and in 0.2.2 Application this will not be possible. I'm not sure what that will mean for examples like this.https://github.com/oam-dev/catalog/blob/master/applications/istio/bookinfo/appconfig-1-bookinfo.yaml
I'm not advocating for a change here BTW, just trying to understand the expected behavior.
Traffic (many of Istio resources are application level, not component level) and hide its complexity. I personally think it's the right way for your platform users to consume Istio, simply embedding raw Istio resources in OAM app definition won't help a lot.
For my next "how do I convert", lets look at a Component to ComponentDefinition example.
Do I have this right? Start with 0.2.1 Component.
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: ...
namespace: ...
spec:
workload:
apiVersion: core.oam.dev/v1alpha2
kind: ContainerizedWorkload
spec:
containers:
- name: ...
image: ...
ports:
- containerPort: ...
name: ...would become 0.2.2 ComponentDefinition
apiVersion: core.oam.dev/v1alpha2
kind: ComponentDefinition
metadata:
name: ...
namespace: ...
spec:
workload:
definition:
apiVersion: core.oam.dev/v1alpha2
kind: ContainerizedWorkload
schematic:
kube:
template:
apiVersion: core.oam.dev/v1alpha2
kind: ContainerizedWorkload
spec:
containers:
- name: ...
image: ...
ports:
- containerPort: ...
name: ...Obviously an increase in complexity with the addition of schematic:kube:template but probably justifiable in order to support different template types. The repetition of the GVK info is a bit irksome for the kube use case though. Perhaps this matters less (or not at all) if the workload information is moved to WorkloadDefinition. It also sort of makes me wonder if there should be a set of unique definition types (e.g. CUEComponentDefinition, HelmComponentDefinition, etc.) although this creates different issues.
1 reply
1 reply
I want to deploy a configmap component and parameterize its value e.g.
-
apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
name: test-configmap
namespace: test-config
spec:
workload:
apiVersion: v1
kind: ConfigMap
metadata:
name: test-cm
namespace: test-config
data:
config-properties.yaml: |
greeting: Hello
parameters:
- name: config-data
required: false
fieldPaths:
- data-
and
-
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: test-appconf
namespace: test-config
annotations:
version: v1.0.0
description: "Test Config application"
spec:
components:
- componentName: test-configmap
parameterValues:
- name: config-data
value:
config-properties.yaml: |
greeting: Howdy-
But this fails to deploy with
The ApplicationConfiguration "test-appconf" is invalid:
- spec.components.parameterValues.value: Invalid value: "object": spec.components.parameterValues.value in body must be of type integer,string: "object"
- : Invalid value: "": "spec.components.parameterValues.value" must validate at least one schema (anyOf)
- spec.components.parameterValues.value: Invalid value: "object": spec.components.parameterValues.value in body must be of type integer: "object"
-
ConfigMap/Secret as part of the component via CUE or Helm templates.
", the value should be decoded. Also, you need to: - parameterize every data item by its key
- name: config-data
required: false
fieldPaths:
- data.config-properties # do not use config.properties- set its value by string like this:
- name: config-data
value: "enemies=aliens\nsecret.code.lives=30 \n"XxxDefinition are now implemented).
Was working through the KubeVela 1.0 install and quick start docs. Tried both KinD and minikube versions. The health check is reporting an error.
$ kubectl get application first-vela-app -o yaml
...
- lastTransitionTime: "2021-05-25T22:14:40Z"
message: 'app=first-vela-app, comp=express-server, trait=ingress, check health
error: get template context: failed to get obj express-server with gvk networking.k8s.io/v1beta1,
Kind=Ingress : ingresses.networking.k8s.io "express-server" not found'
reason: ReconcileError
status: "False"
type: HealthCheckThe ingress appears to be present.
$ kubectl get ingresses -n vela-system express-server
NAME CLASS HOSTS ADDRESS PORTS AGE
express-server <none> testsvc.example.com 192.168.49.2 80 34mThe app is working.
$ curl -H "Host:testsvc.example.com" http://192.168.49.2
<xmp>
Hello World
[removed whale ASCII art]
</xmp>Looks like a version mismatch (i.e. v1 vs v1beta1)? Does the ingress trait definition need to be updated or a different ingress-nginx version installed?
$ kubectl get ingresses -n vela-system express-server -o yaml | more
apiVersion: networking.k8s.io/v1
kind: Ingress
...@resouer Will the issue above prevent rollout from working? I may be misunderstanding how this is supossed to work but I can't make this app roll the pods from image stefanprodan/podinfo:5.2.0 to stefanprodan/podinfo:5.2.1 with these two versions of the application YAML.
First version
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: rollout-app
spec:
components:
- name: rollout-comp
type: webservice
properties:
image: stefanprodan/podinfo:5.2.0
port: 9898
traits:
- type: ingress
properties:
domain: rollout.example.com
http:
"/": 9898
rolloutPlan:
rolloutStrategy: "IncreaseFirst"
rolloutBatches:
- replicas: 50%
- replicas: 50%
targetSize: 3Second version
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: rollout-app
spec:
components:
- name: rollout-comp
type: webservice
properties:
image: stefanprodan/podinfo:5.2.1
port: 9898
traits:
- type: ingress
properties:
domain: rollout.example.com
http:
"/": 9898
rolloutPlan:
rolloutStrategy: "IncreaseFirst"
rolloutBatches:
- replicas: 50%
- replicas: 50%
targetSize: 3
~ >>> helm install --create-namespace -n vela-system kubevela kubevela/vela-core
Error: unable to build kubernetes objects from release manifest: [unable to recognize "": no matches for kind "ScopeDefinition" in version "core.oam.dev/v1beta1", unable to recognize "": no matches for kind "TraitDefinition" in version "core.oam.dev/v1beta1", unable to recognize "": no matches for kind "WorkloadDefinition" in version "core.oam.dev/v1beta1"]