Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Kevin Minder
    @kminder

    @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?

    Lei Zhang (Harry)
    @resouer
    @kminder yes, your assumption is mostly correct (except that trait CR is not 1:1 mapping to app instance). We don't want to allow metadata specified in traits properties. I see you are on a good track to develop a controller for trait, i.e. handle necessary labels/annotation in the controller and expose them as configurable knobs in trait CRD's .spec.
    Lei Zhang (Harry)
    @resouer
    The mindset is Component are sth fully brought by users (or providers), but Traits are features supported in your platform which exposes necessary configurable knobs in application descriptor.
    Kevin Minder
    @kminder
    @resouer < Ok so just to be clear...
    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.
    Lei Zhang (Harry)
    @resouer
    @kminder Yeah, I understand, sorry for not clarify the details clearly in previous meeting. For Istio, the direction is we will implement a global trait named 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.
    we have similar discussion in implementation side as well, see: https://github.com/oam-dev/kubevela/issues/1122#issuecomment-789950529
    Kevin Minder
    @kminder
    Understood. We sort of consider the ability to use "arbitrary" CRDs as a trait (or component) an option of last resort for things our platform does not provide optimized solutions for.
    Lei Zhang (Harry)
    @resouer
    Yeah I can full get that because it was the path we (Alibaba) were before. The lesson learned is, for component, such extensibility is definitely great, and users begin to ask for more power (e.g. Helm, CUE etc). But for traits, this does not work very well (I guess the main reason is operational behaviors are too complex in real world) and create wrong expectations on user side. So the direction we want to go is: give more power to component provider (they can package service/ingress as part of component if they want), and keep Traits focus on real operational behaviors and solve user problems.
    Lei Zhang (Harry)
    @resouer
    Note that this won't mean we want to leave Components unmanaged, on the contrary, more enforcements in implementation side will come since more complexity is coming (e.g. how to rollout the component etc).
    Lei Zhang (Harry)
    @resouer
    In general I feel this direction aligns better with the original motivation to introduce component and traits: we expect user bring a software to the platform, attach add-hoc operational features to it, and deliver them as whole unit. In this context, building a powerful and useful (i.e. features that can not be easily brought or managed by users) trait system will be the main focus of the platform team.
    Kevin Minder
    @kminder

    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.

    Lei Zhang (Harry)
    @resouer
    Your samples align with my mind. I'd keep GVK in schematic as a template is by design to allow user know the full picture, and there's no difference whether it's in workload definition or here. The system already has a way to know what's the template type in any given ComponentDefinition, so we are good for now (at least as a start ^^) since it's a system level concern.
    Luis Ribeiro
    @lribeiro81
    Hi, everyone. This is a very promising project and I'm excited to learn about it.
    I'm trying to write an article to introduce my team to OAM, kubevela and velacp - can I ask a couple of quick questions?
    1 - why was Rudr deprecated? Did the OAM model change a lot from 0.1 to 0.2 and it made more sense to write a new platform from scratch?
    2 - what exactly is the vision for velacp?
    Thank you very much for your help!
    Lei Zhang (Harry)
    @resouer
    @lribeiro81 Thank you Luis! 1. the main reason is because Rudr is written in Rust which is cool and neat , but it set a high bar for new contributors. In v0.1 -> v0.2, OAM itself become fully extensible, so many many contributors come but many are blocked by Rust. Also, some signifiant end users raised similar concern of maintaining a Rust component in their prod env. Hence we made the change. 2. velacp (i.e. kubevela control plane) aims to provide multi-cluster app delivery feature based on OAM as well as DevEx layer (dashboard/cli) atop, please also check this issue: oam-dev/kubevela#1086. Hence, we will migrate all DevEx layer in kubevela repo to velacp when it's ready.
    1 reply
    Lei Zhang (Harry)
    @resouer
    Hi @/all in today's OAM community call (10:30 am PST), we will try to finalize the review process of new release of OAM spec: oam-dev/spec#443, feel free to join the discussion!
    Kush Trivedi
    @kushthedude
    Hi Team, I am interested in GSOC with the OAM community, I have been a past intern with CNCF on Open Service Mesh and have a fair knowledge of k8s and golang. I have already seen the project proposed by the community, any resources on how can I get started with the project?
    Lei Zhang (Harry)
    @resouer
    @kushthedude Hey! Let's start from its doc site: https://kubevela.io, the repo: https://github.com/oam-dev/kubevela, and I saw you've already started looking at oam-k8s-runtime (the dependency lib of kubevela). The first steps include try out guides/samples, find out anything doesn't work and fix it! The formal task will begin per further notice from GSoC.
    1 reply
    Lei Zhang (Harry)
    @resouer
    @kminder One quick update is we now make patch trait (schematic in CUE) work with any component regardless of its schematic approach (Kube, CUE or Helm). Will add some docs recently.
    1 reply
    Lei Zhang (Harry)
    @resouer
    Hey @/all we will start working on releasing the OAM spec v0.3.0 candidate based on the meeting today, please check this tracking issue about the next action items and looking forward to cooperations and contribution: oam-dev/spec#445
    Arjav Desai
    @arjav-desai

    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"
      -
    Yue Wang
    @captainroy-hy
    @arjav-desai according to the schema, only integer and string is acceptable by paramerterValues.value
    Arjav Desai
    @arjav-desai
    Thanks @captainroy-hy, appreciate the quick response! How do you recommend we model the configmap resources as OAM component in this case?
    Lei Zhang (Harry)
    @resouer
    @arjav-desai We in general do not recommend to model ConfigMap/Secret as part of app because they in most cases have independent lifecycles from the app. Though if you insist, I think you just need to declare data value as a string, i.e. "config-properties.yaml: | ....".
    btw, if you are using KubeVela, you could declare ConfigMap/Secret as part of the component via CUE or Helm templates.
    Arjav Desai
    @arjav-desai
    Thanks @resouer , I will try out the string (seems like just " needed). Still using oam-k8s-runtime as library and kubevela.
    Lei Zhang (Harry)
    @resouer
    @arjav-desai Not just ", the value should be decoded. Also, you need to:
    1. parameterize every data item by its key
    - name: config-data
      required: false
      fieldPaths:
        - data.config-properties # do not use config.properties
    1. set its value by string like this:
    - name: config-data
      value: "enemies=aliens\nsecret.code.lives=30 \n"
    Though we never try this before (not aligned with the goal of OAM), so if it dosen't work, let's move to an issue since gitter is hard to discuss examples.
    Arjav Desai
    @arjav-desai
    Thanks @resouer , is this https://github.com/crossplane/oam-kubernetes-runtime/issues right place to file issue, if it comes to that?
    1 reply
    Lei Zhang (Harry)
    @resouer
    Hey @/all OAM community call starts at 10:30 PST. We will finalize reviewing OAM spec v0.3.0 PR in today's meeting.
    Luis Ribeiro
    @lribeiro81
    Hi everyone, I'm having some trouble with some concepts, such as the difference between WorkloadDefinition and ComponentDefinition; could someone clarify?
    Lei Zhang (Harry)
    @resouer
    @lribeiro81 Please check this diagram which explains the OAM resource model: https://kubevela.io/docs/next/concepts#summary
    Lei Zhang (Harry)
    @resouer
    ComponentDef is designed as an abstraction and encapsulation atop of WorkloadDef. So your platform normally have limited number of workload definitions (e.g. stateless, stateful, job), but countless component definitions declared by users (e.g. web-service, tf-training, my-awesome-blog etc).
    11 replies
    Lei Zhang (Harry)
    @resouer
    Hence, the ComponentDef intends to support various ways (raw template, Helm, and CUE) to encapsulate the workload definition.
    Lei Zhang (Harry)
    @resouer
    Hey @/all OAM community call starts at 10:30 PST. We are very close to release OAM spec v0.3.0 in today's meeting.
    Lei Zhang (Harry)
    @resouer
    Hey @/all, OAM community call is in 30mins! We will update the status on spec v0.3.0 releasing and KubeVela (particularly, the revisions of XxxDefinition are now implemented).
    Hongchao Deng
    @hongchaodeng
    Hi @/all . Today's community call is cancelled. Harry has a meeting conflict. I have a sore throat today which came up this morning. No one can host the meeting atm. Thanks all for your interests and attention. Look forward to seeing you next time.
    Kevin Minder
    @kminder

    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: HealthCheck

    The 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      34m

    The 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
    ...
    Lei Zhang (Harry)
    @resouer
    @kminder yes it seems the trait definition needs upgrade, mind to fire an issue on this? it should be a quick fix.
    Kevin Minder
    @kminder
    Created oam-dev/kubevela#1726 Ingress trait definition uses old Ingress CRD
    Kevin Minder
    @kminder

    @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: 3

    Second 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
    4 replies
    Lei Zhang (Harry)
    @resouer
    @/all In tomorrow's OAM Community Call (10:30 am PST), we will introduce a draft design of "app level operational capabilities", please feel free to add yourself in the agenda doc: https://docs.google.com/document/d/1nqdFEyULekyksFHtFvgvFAYE-0AMHKoS3RMnaKsarjs/edit#heading=h.fxheg997ppgf
    Kevin Minder
    @kminder
    Getting certificate validation errors today on https://kubevela.io/
    Anyone else?
    1 reply
    Edgar Contreras
    @mredvard
    hi, I hope this is the right channel, I'm having issues installing kubevela in my cluster

    ~ >>> 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"]

    Edgar Contreras
    @mredvard
    Solved, I got oam crds definitions from another project
    1 reply