ComponemtDefinion.Spec should have a list of workload/schematics objects

[blaggacao]

Unless I misunderstand something, the 1:1 mapping of Spec to exactly one workload and one schematics looks like countering the desigen principles.

Isn't the idea precisely to make an Application agnostic of the scheduler platform so that it can be ported across different platforms?

Or is the impetus to reimplement the exact same fully qualified CompomemtDefinition on a different platform (by the platform team) with a different workload/schemantics pair (but the same parameter contract)? This is wired because it essentially signifies aliasing (only aparent and context sensitive) "fully qualified" names.

[wonderflow]

Good question, ComponentDefinition in OAM is a contract from abstraction to Implementation details, the abstractions is the component type which is the name of ComponentDefition, along with the schematic of the component which is the parameter defined in schematics. We can replace or update one ComponentDefintion from another with the same name and same parameters schematic but different Implementation, this way let us achieve the goal of platform agnostic.

For example, we need a helm component type, we can implement it by using FluxCD or ArgoCD, so we can define the ComponentDefinition like:

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  name: helm
spec:
  schematic:
    cue:
      template: |
         parameter:{
             url: string
             chart: string
             version: string
         }
         output:{
             apiVersion: "argoproj.io/v1alpha1"
             kind: "Application"
             ...
         }     

The full example of this definition can be found here, it's defined in CUE but can be converted to OAM api when applied into k8s.

Or we can define it by using fluxcd like:

apiVersion: core.oam.dev/v1beta1
kind: ComponentDefinition
metadata:
  name: helm
spec:
  schematic:
    cue:
      template: |
         parameter:{
             url: string
             chart: string
             version: string
         }
         output:{
             apiVersion: "helm.toolkit.fluxcd.io/v2beta1"
             kind: "HelmRelease"
             ...
         }     

The full example of this definition can be found here.

As to say the workload, I think it could be omitted in this case.

[blaggacao]

All clear, thank you. So it's "aliasing" (contracts) for each Workload that the scheduler platform team would provide locally.

I had thought ComponentDefinitions have a global identity.

It looks like the actual parameter contract might be abstracted away and made global, though.

---

By the way, I have the impression a lot of this is working around the yaml hell, very fundamentally.

Maybe the project would be able to benefit from Nickel (think cue with much better error reporting strategy) as your data wrangler.

https://github.com/tweag/nickel

It's functional. :heart:

[wonderflow]

It looks kike the actual parameter contract might be abstracted away and made global, though.

Yes, we're also feeling this can be a standard registry for all common types and parameters. The implementation can be automatically registered and discovered.

Something like:

component  |  implemetation registered     |  enabled 
   -       |               -               |    - 
helm       |   fluxcd, argocd               |  fluxcd 
webservice  |   Deployment, StatefulSet      |  Deployment

Thanks @blaggacao for introducing nickel, we'll look into it.

[wonderflow]

I think we can keep this issue open to support component/trait standard registry and track the idea. \cc @Somefive @wangyikewxgm