[Design Proposal] Add a generic mechanism for traits to work with workloads in OAM runtime about oam-kubernetes-runtime HOT 10 CLOSED

• Fetch all the childResources from the corresponding workloadDefinition CR.
• List each child resource by its type and filter by owner reference. Here, we assume that all the child resources that the workload generates have an owner reference field pointing back to the workload instance.

These steps are too verbose. We can do an alternative that by adding child object references in the annotations of workload CR, this can be simplified and easier to understand. Here's an example:

kind: ContainerizedWorkload
metadata:
  annotations:
    core.oam.dev/child-objects: "..."

from oam-kubernetes-runtime.

These steps are too verbose. We can do an alternative that by adding child object references in the annotations of workload CR, this can be simplified and easier to understand. Here's an example:

Who would put that info in the workload CR? It seems that appConfig controller would have no idea.

from oam-kubernetes-runtime.

It seems that appConfig controller would have no idea.

It is the appConfig controller actually because it has all the context to watch child resources created, filter owner references, and attaching those info back.

from oam-kubernetes-runtime.

@ryanzhang-oss Let's make this a PR so folks can leave comment easier?

Here's a perfect place for proposals: https://github.com/crossplane/crossplane/tree/f86e47e06fd5d221b33f29847bf4e12813f769da/design

from oam-kubernetes-runtime.

Agree. Making it a proposal would be a great start to have a well defined, unambiguous direction for implementation.

To make a proposal, we should structure this more user friendly, and have a end2end user story.

First of all, the title should be focused on adding a new trait from user perspective. Currently the title is too implementation focused. From platform builder's POV, Trait is a reusable module in OAM. A platform builder can add a new trait for specific operational capability and have it plugged into any OAM platform.

Second, we should demonstrate at least 2 user scenarios in the proposal:

Scenario 1 (Bespoke): Implement a new trait

Let's say a platform builder has a custom workload object called MyDeployment, and wants to add a new operational function called MyCanaryRollout to MyDeployment. In this case, he is building a bespoke trait and needs to understand how to interact with OAM runtime? This includes how to get the MyDeployment object and its child resources, what are the other traits (e.g. traffic split and monitoring metrics), etc. We need to demonstrate what OAM capabilities to help him build that.

The problem to solve in this scenario is to make a platform builder know how to implement a new trait and add it to OAM.

Specifically, we should cover at least two things:

1. Standardized trait implementation workflow. The data (labels, annotations, fields) and the hooks (when should reconcile happen).
2. SDK to help developer interact with the OAM runtime to achieve data and focus on business logic.

Scenario 2 (COTS): Reuse an existing trait

Let's say an OAM user has a standard ContainerizedWorkload deployment, and retrieves a monitoring trait from others. In this case, he is deploying a COTS trait and needs to understand what does OAM do? This includes putting the restrictions on trait and component relationship (appliesTo field), conflicts (oam-dev/spec#352), potentially ordering as discussed in #11, etc.

The problem to solve in this scenario is to make a user understand how adding an existing trait affects his current workflow.

from oam-kubernetes-runtime.

"Add a childResources field in the WorkloadDefinition."
It only works for simple 1-1 mappings. One Workload to one service and to one deployment. It does not work if there is a more complex logic involved to generate those. We should define an interface instead. This way, how one particular WorkloadType maps to CRDs is abstracted and just matters at runtime.

"ApplicationConfig controller add labels containing the workload information to the emitted trait CR."
App operator should not need to describe how the trait is applied - we are removing value from OAM if we start to peal out the abstraction. The app operator just applies the Trait to the Component in AppConfig and the implementation knows how to apply it. In this case, if we want to make this extensible, it feels like another interface.

My general feedback is to not pollute the spec due to implementation details. We should try to make this library extensible without creating an OAM's sub-spec. We should be defining an API instead.

from oam-kubernetes-runtime.

Echo to this comment: https://github.com/crossplane/crossplane/issues/1448#issuecomment-620275559

I agree we should try best to simplify the workflow in Trait controller by annotating GVK + name (not sure if possible) of child resource on Workload CR. There's several approaches to do this and we can follow up the discussion on the upcoming proposal.

from oam-kubernetes-runtime.

proposal: crossplane/crossplane#1454

from oam-kubernetes-runtime.

Per #55 we're centralising all things OAM in one repo, and oam-kubernetes-runtime seems like the leading candidate. I'm going to move this issue there.

from oam-kubernetes-runtime.

Closing as it already implemented https://github.com/crossplane/oam-kubernetes-runtime/blob/master/design/one-pager-trait-workload-interaction-mechanism.md

from oam-kubernetes-runtime.