Workload settings in 0.2.2 WD

[BBialeckiACR]

Workload settings moving to the application configuration first makes the workload parameters irrelevant. Parameters were designed to allow component developers to make settings mutable or require user input, but not to define an entire unique instance. Unique instances need to follow schemas approved by the platform and be defined by a component developer.
My issues are that I only want component users and app deployment staff to have to enter limited information if any for a component. I make these mutable or required as parameters when defining my unique component instance. Also by not creating default schemas that a platform hosts and a component developer leverages, the platform opens itself up to invalid components being defined that it cannot support and it has to validate schemas one setting at a time without a truly valid standard dictionary to use for platform supported settings.
Therefore the request is that WorkloadDefinitions remain part of core, standard and extended portions of the spec and these definitions are used to define the capabilities of a Platform.
Component developers find a Platform instance that has a WorkloadDefinition schema with settings that can be used for their component and defines the component using the available Platform schema. When a developer wants a user to be able to change a setting (makes it mutable) or requires a user to provide input for their component instance, such as hostname, they make this and only this a parameter.

[kminder]

I've come to the conclusion that there may be terminology issues here leading to confusion. My current understanding is that WorkloadDefinition as described in 0.2.2-WD is logically similar to Component in 0.2.1. Meaning that in 0.2.2-WD WorkloadDefinitions are intended as a set of parameterized "templates" that can be instantiated via a references in Applications.

If my new interpretation is correct this does eliminate the ability to query the platform for a list of supported component types. For example a component provider must assume that any existing CRD could be used within a WorkloadDefinition. Is this a correct assumption?

The "new" WorkloadDefinitions I see (i.e. task, webservice, worker) more or less make sense in this adjusted model. These describe reusable parameterized templates that can be instantiated via references in Applications. I note that they do not contain metadata that I thought was was intended to be used by trait implementations (e.g. childResourceKinds). How can a trait ever be implemented to generically handle unknown future workload definitions?

This leads me to consider the current containerizedworkloads.core.oam.dev workload definition. How can the existing ConainerizedWorkload be meaningfully used in an Application as they do not contain a parameterized resource template?

[resouer]

@kminder Yes, it's the intention to make v0.2.2 WorkloadDefiniton include all schema (i.e. templating, parameters) features of ComponentSchematic and Component in prior releases, it will then fix the issue that the original component concept mixed both schema and instance information.

How can a trait ever be implemented to generically handle unknown future workload definitions?

However, the new design indeed keeps the idea of workload type identifier in the prior releases:

apiVersion: core.oam.dev/v1alpha2
kind: WorkloadDefinition
metadata:
  name: webservice
  annotations:
    definition.oam.dev/description: "Long-running scalable web service with network endpoint"
spec:
  definitionRef: # <--- this is the workfload type identifier
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkloads
    # name: containerizedworkloads.core.oam.dev # you can also use name instead of GVK (not recommend)
  template:
    ...
  parameters:
    ...

Traits impl use definitionRef to know the workload type of this webservice component is containerizedworkloads.core.oam.dev. Nothing changed here.

How can the existing ConainerizedWorkload be meaningfully used in an Application as they do not contain a parameterized resource template?

ConainerizedWorkload is a workload type, not a WorkloadDefinition (i.e. a Component definition), how to template this workload has been illustrated in above sample.

The argument is why we don't introduce a WorkloadType object (it's also mentioned in kubevela/kubevela#1064). Actually, we have already experimented this idea before (see this AlibabaCloud ROS workload type). The feedback is not good since it brings another layer of complexity but with limited value. The main issue is in Kubernetes context, workloads have already been identified by its GVK resource, so it makes more sense to discover the controller by workload GVK directly (we have already built a tool to do this: https://github.com/cloudnativeapp/CLM, it works well), having a WorkloadType only make sense for non-k8s context (as the AlibabaCloud example above).

The direction I currently hoping to go is ensure user can rely on a single definition object to carry all needed information to define a reusable component. I am open to rename it to ComponentDefinition of course, and open to enable WorkloadType based on this direction. FYI, I just proposed a idea here: kubevela/kubevela#976 (comment) (i.e. having both ComponentDef and WorkloadDef)

[resouer]

xref: revisioning template modules in definition (kubevela/kubevela#1064)