[BUG] The "config" attribute is not working for ContainerizedWorkload

[mgianatagh]

Describe the bug
The config attribute within a container for a ContainerizedWorkload is not working or implemented.

To Reproduce

1. Create and apply a Component definition for a ContainerizedWorkload that specifies a config.

For example:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: mysql
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    metadata:
      name: mysql
      labels:
        app: mysql
    spec:
      containers:
        - name: mysql
          image: "mysql:8.0.20"
          ports:
            - name: mysql
              containerPort: 3306
              protocol: TCP
          config:
            - path: /docker-entrypoint-initdb.d/initdb.sql
              value: test

2. Create and apply an ApplicationConfiguration using the component.

For example:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: mysql
  annotations:
    version: v1.0.0
    description: "test"
spec:
  components:
    - componentName: mysql

3. Use kubectl to exec into themysql pod and do an ls /docker-entrypoint-initdb.d/initdb.sql. No such file will be found.

Expected behavior
I expected to see the file /docker-entrypoint-initdb.d/initdb.sql get created in the container and have the contents be test.

Screenshots

Cluster information

kubectl version

Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.8", GitCommit:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState:"clean", BuildDate:"2020-08-13T16:12:48Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.8", GitCommit:"9f2892aab98fe339f3bd70e3c470144299398ace", GitTreeState:"clean", BuildDate:"2020-08-13T16:04:18Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}

Additional context
I searched the code and it did not appear that the fields Path and Value in the type ContainerConfigFile were being used.

[hongchaodeng]

The config section was defined very early on in the beginning of the project. Its use case doesn't seem very valid now.

I think we should get rid of it and use the podSpec to pass env or mount secret/configMap would be enough.

[resouer]

A little more background to echo Hongchao's comment:

• The ContainerizedWorkload schema was designed as the "serverless container" style workload, think about Azure ACI or AWS Fargate. It's designed to be self-contained so user doesn't need to handle auxiliary objects like ConfigMap/Secret etc. The drawback is it's kinda restricted for other/more generic scenarios.
• The newly introduced PodSpecWorkload schema is designed as generic PaaS workload which adopts full Kubernetes pod spec, but user will need to handle ConfigMap/Secret etc by himself.

Not sure which abstraction level matches best to your scenario @mgianatagh?

At the mean time, the config implementation should be fixed in its workload controller.

[mgianatagh]

Thank you, I will take a look at the PodSpecWorkload, I was not aware of that yet.

My initial setup of deploying mysql was to use three component files to create a ConfigMap, Deployment and Service. That approach worked fine. I was experimenting to see if I could consolidate into a single component file using the ContainerizedWorkload.

[wonderflow]

I used to implement it in rudr oam-dev/rudr#149. I think we could use the similar way to do so.

@captainroy-hy Would you like to have a try?

[captainroy-hy]

I used to implement it in rudr oam-dev/rudr#149. I think we could use the similar way to do so.

@captainroy-hy Would you like to have a try?

Sure, I will work on it.