[Feature] Helm chart as capability module

[resouer]

Is your feature request related to a problem? Please describe.

Consider using Helm Chart as Component (by referring a chart as WorkloadDefinition module)

As helm chart already provide both templating and parametering, and many platform builders know how to make helm chart (correct me if I'm wrong).
Furthermore, the chart also provides json schema, so many things work today (e.g. doc-gen, openapi-schema-gen) still work.

And user will also be able to use AppDeployment to rollout the workload, this process could be naturally integrated with GitOps tool (Flux or ArgoCD) to form a modern app delivery system: GitOps to sync the app, and AppDeployment to rollout/rollback the app.

What about Traits?

Similarly, trait can also be provided by Helm chart in TraitDefinition. KubeVela will be responsible to inject correct workload ref as today (ideally, via .values, instead of hacking Helm templating thing). This also means we will NOT allow packaging traits templates (such as HPA, Ingress, etc) in a workload module (Service is part of the it though).

The alternative is, we allow platform team package traits together with workload templates in same chart and allow WorkloadDefinition and TraitDefinition ref same chart as provider. But this seems heavily impacted the clarity and flexibility (unless we use sub-chart).

/cc @ryanzhang-oss who has expressed interested on this, and open for further discussion.

A off topic issue is we should move template related fields out of extension, they have been proven to be useful (and this is NOT a break change).

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[hongchaodeng]

I think this is the problem that the Catalog and Package design resolves.

One difference is that, instead of putting the modules in the Definition yaml, the design creates another abstraction called Catalog to manage them. In this way, we can decouple the Capability Definition and Package, because they are stored and managed in separate logical workflows and physical places.

[wonderflow]

If we close the issue when we have only merge a design proposal, do we need to raise a new issue to implement the design?

[resouer]

It's automatically closed by keyword. Reopen.

Also, this issue has nothing related to existing catalog design. /cc @wonderflow

An off-topic but the missing part for catalog is Environment design, which should include installation of capability dependency (per design of catalog).

[resouer]

Draft design idea (based on Helm operator from Flux):

The definition for this chart based component:

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition # ComponentDefinition
metadata:
  name: webapp-chart
spec:
  module:
    helm:
      chart:
        spec:
          chart: podinfo
          sourceRef: # TODO: can also embed repo source CRD here
            kind: HelmRepository
            name: podinfo
            namespace: flux-system
      interval: 5m
      install:
        remediation:
          retries: 3

How user defines the app:

apiVersion: core.oam.dev/v1alpha2
kind: Application
metadata:
  name: myapp
  namespace: demo
spec:
  components:
    - name: podinfo # helm chart release name
      type: webapp-chart # definition = helm chart
      settings: # helm chart values
        cache: redis-master.redis:6379
        ingress:
          enabled: true
          annotations:
            kubernetes.io/ingress.class: nginx
          path: "/"
    - name: cache # a redis cloud resource
      type: aws-redis
      settings:
        sku: big

[wonderflow]

Draft design idea (based on Helm operator from Flux):

The definition for this chart based component:

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: webapp-chart
spec:
  module:
    helm:
      chart:
        spec:
          chart: podinfo
          sourceRef: # TODO: can also embed repo source CRD here
            kind: HelmRepository
            name: podinfo
            namespace: flux-system
      interval: 5m
      install:
        remediation:
          retries: 3

How user defines the app:

apiVersion: core.oam.dev/v1alpha2
kind: Application
metadata:
  name: myapp
  namespace: demo
spec:
  components:
    - name: podinfo # helm chart release name
      type: webapp-chart # definition = helm chart
      settings: # helm chart values
        cache: redis-master.redis:6379
        ingress:
          enabled: true
          annotations:
            kubernetes.io/ingress.class: nginx
          path: "/"
    - name: cache # a redis cloud resource
      type: aws-redis
      settings:
        sku: big

Yes, I think we could get start with this thing. The definition and the usage could be like your draft design.

The model layer information could be labels that manually added by the chart builder, just like: https://docs.fluxcd.io/en/stable/references/helm-operator-integration/#annotations

[wonderflow]

We can make this happen in v1.0

[resouer]

Please kindly consider real world examples like https://github.com/stefanprodan/podinfo/tree/master/charts/podinfo/templates. i.e. there are cert, hpa ingress packaged in this component. We should document the restriction if user want to leverage Rollout capability.