support multi kinds in abstract layer containerizedworkload

[jack0liu]

In the abstract layer containerizedworkload, currently only the deployment is supported.

One user case : An app contains two components, one is deployment, another is statefulset. For simplifying definition with OAM way， we use containerizedworkload as component workload.

Example:

The storage-api is not stateful, it maybe work well with containerizedworkload:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: storage-api
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    spec:
      containers:
        - name: storage-api
          image: storage-api:4.6.1-apache
          ports:
            - containerPort: 80
              name: storage-api

The file-storage is stateful, it should not be a deployment, but a statefulset. and in the beginning, just let it running well, and later we should attach a replica-trait to make the statusful component exptend:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: file-storage
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    spec:
      containers:
        - name: file-storage
          image: file-storage: 1.0.0

[wonderflow]

I have a immature idea:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: app
spec:
  components:
     - componentName: file-storage
        traits:
          - trait:
               apiVersion: extended.oam.dev/v1alpha2
               kind: Stateful
               spec:
                  stateful: true
     - componentName: storage-api

The Stateful trait could be a patch trait, and the two workload created can be:

   apiVersion: core.oam.dev/v1alpha2
   kind: ContainerizedWorkload
   metadata:
       name: storage-api
       annotations:
           child.resource.type: default
   spec:
     containers:
       - name: storage-api
         image: storage-api:4.6.1-apache
         ports:
           - containerPort: 80
             name: storage-api

    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    metadata:
        name: file-storage
        annotations:
            child.resource.type: statefulset
    spec:
      containers:
        - name: file-storage
          image: file-storage: 1.0.0

The annotation part could be a patch provisioned by Stateful trait.

        annotations:
            child.resource.type: statefulset

And finally the controller of ContainerizedWorkload could recognize the annotation and use Statefulset as child resource.

@jack0liu Would this solve your problem?

[jack0liu]

@wonderflow yes, i believe that it will work. but that usage doesn't seem to match the concept of the trait, would customers be confused with the definition of trait?

[wonderflow]

@jack0liu A better name will solve it

[barnettZQG]

 annotations:
      child.resource.type: statefulset

This form can be regarded as experimental. It would be more instructive to add the ControllerType directly to the Spec if this design is well accepted and well-practiced.