Expectation related to instantiating components on ApplicationConfiguration

[dhiguero]

We have found an issue related to the expectations of what happens with a component on an ApplicationConfiguration entity. Launching the containerized-workload example once, and then copying the ApplicationConfiguration, changing its name, and launching it again produces the following output:

"status": {
        "conditions": [
            {
                "lastTransitionTime": "2021-01-14T15:42:04Z",
                "message": "cannot apply components: cannot apply workload \"example-component\": existing object is not controlled by UID \"40502b95-8c1a-4353-884d-94e23bdffbc0\"",
                "reason": "ReconcileError",
                "status": "False",
                "type": "Synced"
            }
        ],
        "dependency": {},
        "observedGeneration": 1
    }

On the ApplicationConfiguration spec related to the component it says

The name of the component of which to create an instance. The revision of this instance will always reflect the latest change of the component (i.e. always track latest revision). This is mutually exclusive with revisionName.” so we understood that a component once defined can be reused by many application configurations.

We believe this is a desired and expected outcome since it will improve reusability and we already have a parameterValues attribute. In this way, we think that having reusable components among different ApplicationConfigurations would be ideal. From other parts of the spec, this approach seems to be expected

Components describe functional units that may be instantiated as part of a larger distributed application. For example, each microservice in an application is described as a component. The description itself is not an instance of that microservice, but a declaration of the operational capabilities of that microservice.

We are aware of other proposed entities such as the ComponentSchematic which are defined as

... can be either a template for configuration values according to a fixed schema (the containers array), or define both schema and configuration values (the workloadSettings object)

One alternative to introduce this feature using the current entities could be to modify the ApplicationConfiguration to include a new reference so it is clear for the runtime that we expect to make a new copy of a component (creating a new instance) instead of linking it to an existing one:

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: example-appconfig
spec:
  components:
    - componentName: my-new-example-component
      parameterValues:
        - name: image
          value: wordpress:php7.2
      componentRef:
        apiVersion: core.oam.dev/v1alpha2
        kind: Component
        name: example-component
  ...

What do you think?

[resouer]

@dhiguero Thank you for bringing up this issue, this is exactly what we want to fix in the v0.2.2 release of OAM spec.

The root cause of this issue, as you've already posted, is ComponentSchematic mixed workload schema (i.e. template + parameters) and configuration values (i.e. .workloadSettings) in the same object. This caused a lot of confusion and make it very tricky to manage the underlying workload instance in implementation, because a ComponentSchematic could be a instance or a template depending on how user defines it.

Thus, we decided fix issue by splitting all the schema related fields into a seperate object named WorkloadDefinition in v1alpha2, then deprecate ComponentSchematic, and use a new object named Component to represent the configuration values of workload.

The change from v1alpha1 to v1alpha2 (release v0.2.1)

In this context, the objects that will be shared across applications are always definition objects (because they ARE templates)

Note that the changes above is not fully reflected in v0.2.1 spec release, for example, the .parameters are still defined in Component, this is not correct and it should be moved to WorkloadDefinition. Another TODO is we should add .template to WorkloadDefinition. Hence, we began to work out v0.2.2 spec release (the current working draft).

While at the same time, we decided to finish v0.2.2 on implementation side first so to get enough feedback from community, especially on how to do templating and parameterizing. It's why KubeVela project comes out and why we experimented using CUE as the template and parameters in definition objects. The feedback is great in general, and we also received feedback that we should support Helm chart as template in definitions, which indeed makes sense to me.

Based on these feedbacks, we've almost completed the v0.2.2 release of OAM spec on KubeVela side today, it evolves from the current release naturally like below:

The change from v1alpha2 (release v0.2.1) to v1alpha2 (release v0.2.2)

Detailed examples can be found here: Application, Definitions.

Note that we temporarily removed the .parameterValues part in Application. This doesn't mean it will be deprecated, on the contrary, this feature is so valuable that worths a seperate object to reflect the idea of "runtime configuration of the app". Hence, after the Application + Definitions spec are released, some follow up model objects im my mind will be:

1. ApplicationBinding which carries the runtime configuration values to override the values in Application. The key difference here is we can even override the traits values in this case. The user scenario will be cross-envs deployment.
2. ApplicationDeployment which handles rollout and traffic of the Application. Previously rollout is a trait (i.e. part of the app), it works, but it makes more sense to define rollout separately since it need to handle multiple revisions of the app.

In implementation, Component (C) + AppConfig (AC) will still be long term supported as backward compatibility for existing v0.2.1 based platforms. Note that this also means C + AC will NOT be part of core OAM spec in the future

So back to this issue, I feel we can ignore the v0.2.1 release (Component + AppConfig), and directly look at the change from v1alpha1 to v0.2.2 release. The change is below:

Summary: the change from v1alpha1 to v1alpha2 (release v0.2.2)

In detail:

• ComponentSchematic is replaced by WorkloadDefinition, and all schema related features will be moved to definition object (i.e. parameters and template).
• Similarly, Traits is renamed to TraitsDefinitions. ALL the definition objects are sharable and reusable across apps.
• ApplicationConfiguration is renamed to Application, and it still represents the whole instance of the app.
  • The .workloadSettings is moved to this object (done in v0.2.1).
  • The .parameterValues is not needed any more as what Application contains are all parameter values. For runtime configurations like ApplicationBinding, it's non-goal for v0.2.2.

A demo workflow for v0.2.2 could be found here.

Hopefully above background and summarize could help to explain what's happening (v1alpha1 -> v0.2.2), so we can evolve the spec following this direction together.

We are also eager to onboard more maintainers to join the team and fix the spec alongside with the implementation.

[dhiguero]

Thanks @resouer for the comprehensive response on this issue. We will take this into consideration for our next release, and we are looking forward to extend our collaboration in the community.