Support complex/object data type for parameterValues in ApplicationConfiguration

[arjav-desai]

Is your feature request related to a problem? Please describe. ConfigMap allows for data to be specified as complex type 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

When we try to overwrite this parameter in appconf e.g.

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

This fails 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"

Describe the solution you'd like Had raised this on gitter and was informed that current schema for app conf supports only int and string i.e. https://github.com/crossplane/oam-kubernetes-runtime/blob/da0b655dffd20a75d3f31a1315df282aa8f26ecd/charts/oam-kubernetes-runtime/crds/core.oam.dev_applicationconfigurations.yaml#L291-L302

I would parameterValues to support complex/object type.

Describe alternatives you've considered

• Not map ConfigMap as component.
• Defined each key-value pair independently and specify override for each of them. This is super tedious and not user friendly.

Additional context

• NA

[wonderflow]

Would you like to try KubeVela( https://kubevela.io/ ), it's the implementation of OAM v0.3 . And its Application(https://kubevela.io/docs/application) Object can support almost every complex types by CUE/Helm schematic, while also support the old way here as Raw Template schematic.

[resouer]

We normally consider ConfigMap/Secret (i.e. the carrier of external data) not part of the application definition (i.e. model with components). Though if that's the preference, using CUE or Helm to package them in component definition is the recommended approach, per se comment above.

We do not have plan to extend raw resource template beyond simple key-value pair as this will essentially reinvent CUE or Helm (go-tmpl).