[Component] Workload metadata vs spec? Workload name?

[artursouza]

Issue

What is the use of workload name in Component? There is only one workload per Component, so what is the reason for metadata AND spec? Name seems useless when consuming a Workload in Component and all configuration of the workload goes into spec.

Proposal

Remove metadata when consuming Workload or make metadata optional.

[negz]

There is a one-to-many Component-to-Workload relationship. Think of a Component as a template an ApplicationConfiguration may use to produce a Workload. When N ApplicationConfigurations reference 1 Component N instances of the Workload will be produced. So, the use of the workload name is to specify, given an ApplicationConfiguration, what the workload should be named.

I think the current implementation is pretty flexible.

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: coolcomponent
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
    metadata:
      name: potato

You could write the above, but doing so would only make sense if the Component was only used by exactly one ApplicationConfiguration. When a second ApplicationConfiguration attempted to use the Component it would fail, because it would try to create a ContainerizedWorkload named "potato" when one already existed (and was controlled by another ApplicationConfiguration).

Instead it's usually better to write:

apiVersion: core.oam.dev/v1alpha2
kind: Component
metadata:
  name: coolcomponent
spec:
  workload:
    apiVersion: core.oam.dev/v1alpha2
    kind: ContainerizedWorkload
  parameters:
  - name: instance-name
    description: Name of this workload
    required: true
    fieldPaths:
    - metadata.name

Thus allowing multiple ApplicationConfigurations to reuse the same Component, as long as each ApplicationConfiguration specifies a unique name for the workload the Component will produce.

We might consider making a Component's spec.workload.metadata optional, but recall that objects are uniquely identified by their group, kind, and name. If spec.workload.metadata were optional we'd need some deterministic way to name each workload that remained stable over time. I considered:

• appconfigname-componentname - Limits the appconfig to using each component at most once.
• appconfigname-componentname-componentindex (where index is the component's position within the appconfig's array of components) - Requires the array of components that an appconfig references to remain fixed for the lifetime of the appconfig.

[artursouza]

This is the part where it was not obvious. Does it mean an app with multiple components can also be represented as a component with multiple workloads?

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: Nic Cope [email protected] Sent: Friday, March 13, 2020 4:43:05 PM To: oam-dev/spec [email protected] Cc: Artur Souza [email protected]; Author [email protected] Subject: Re: [oam-dev/spec] [Component] Workload metadata vs spec? Workload name? (#333)

There is a one-to-many Component-to-Workload relationship. Think of a Component as a template an ApplicationConfiguration may use to produce a Workload. When N ApplicationConfigurations reference 1 Component N instances of the Workload will be produced. So, the use of the workload name is to specify, given an ApplicationConfiguration, what the workload should be named.

I think the current implementation is pretty flexible.

apiVersion: core.oam.dev/v1alpha2 kind: Component metadata: name: coolcomponent spec: workload: apiVersion: core.oam.dev/v1alpha2 kind: ContainerizedWorkload metadata: name: potato

You could write the above, but doing so would only make sense if the Component was only used by exactly one ApplicationConfiguration. When a second ApplicationConfiguration attempted to use the Component it would fail, because it would try to create a ContainerizedWorkload named "potato" when one already existed (and was controlled by another ApplicationConfiguration).

Instead it's usually better to write:

apiVersion: core.oam.dev/v1alpha2 kind: Component metadata: name: coolcomponent spec: workload: apiVersion: core.oam.dev/v1alpha2 kind: ContainerizedWorkload parameters:

• name: instance-name description: Name of this workload required: true fieldPaths:
  • metadata.name

Thus allowing multiple ApplicationConfigurations to reuse the same Component, as long as each ApplicationConfiguration specifies a unique name for the workload the Component will produce.

We might consider making a Component's spec.workload.metadata optional, but recall that objects are uniquely identified by their group, kind, and name. If spec.workload.metadata were optional we'd need some deterministic way to name each workload that remained stable over time. I considered:

• appconfigname-componentname - Limits the appconfig to using each component at most once.
• appconfigname-componentname-componentindex (where index is the component's position within the appconfig's array of components) - Requires the array of components that an appconfig references to remain fixed for the lifetime of the appconfig.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Foam-dev%2Fspec%2Fissues%2F333%23issuecomment-598974345&data=02%7C01%7C%7Ceaf8f42af6fb485d40f508d7c7a84742%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637197397865876470&sdata=ICtXlsNOQAenyZV%2BwpoyLF9HgQACzwKMJip1%2BH2t0Tg%3D&reserved=0, or unsubscribehttps://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAA77CVDMAJJOSMCR63E44DRHLAITANCNFSM4LHMLBMA&data=02%7C01%7C%7Ceaf8f42af6fb485d40f508d7c7a84742%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637197397865886462&sdata=F3v3tOjY%2Fzc4Fs7xr26V%2ByhfygGsQMew3UmaAT05PEc%3D&reserved=0.

[negz]

Does it mean an app with multiple components can also be represented as a component with multiple workloads?

I'm not sure if I understand what you're asking, but I think the answer is no. 😄 Each component may include a template for only one workload. It's not possible for one ApplicationConfiguration to reference one Component one time to produce three Workloads.

An ApplicationConfiguration could however reference one Component three times to produce three Workloads.

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: coolapp
spec:
  components:
  - componentName: coolcomponent
    parameterValues:
    - name: instance-name
      value: coolapp-coolworkload

The above appconfig references one component one time. The referenced component must contain a template for exactly one workload, so this appconfig will always produce one workload.

apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
  name: coolapp
spec:
  components:
  - componentName: coolcomponent
    parameterValues:
    - name: instance-name
      value: coolapp-coolworkload-a
  - componentName: coolcomponent
    parameterValues:
    - name: instance-name
      value: coolapp-coolworkload-b

The above appconfig references one component two times (notice both entries in the spec.components array refer to componentName coolcomponent). The referenced component must contain a template for exactly one workload, so this appconfig will always produce two workloads.

[artursouza]

My initial understanding of 1 component to 1 workload was correct, then.

So, the workload name is what is being used to differentiate two references of the same component in ApplicationConfig?

[negz]

So, the workload name is what is being used to differentiate two references of the same component in ApplicationConfig?

Sort of. This probably makes more sense if you think of a Component as an opaque template that an ApplicationConfiguration may use to produce a Workload. I wouldn't quite say the Workload name differentiates two references to the same Component, so much as it differentiates the Workloads the ApplicationConfiguration produces using that Component.

UX wise the idea is that the application operator wants to deploy an application. A deployed application is a bundle of related Workloads. A Component is a template for producing a kind of workload for a particular purpose. The application developer writes the Component, explicitly specifying any fields that never vary between applications (e.g. health probe paths, env var names). The application developer exposes the fields that may vary between applications as parameters that the application operator may modify.

[zhxu2]

My initial understanding of 1 component to 1 workload was correct, then.

So, the workload name is what is being used to differentiate two references of the same component in ApplicationConfig?

my understanding is the workload name is a reference to workload interface (CRD). Spec is used to instantiate workload (create CR).