How Traits can be composed in order？

[wonderflow]

Now in rudr, we have implementation to manage whether the trait manager need to execute trait before Component create/modify/delete or after.

So I suggest we add field like stage in Trait to define the compose order.

apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
  name: Ingress
  annotations:
    version: v1.0.0
spec:
  stage: afterStart/afterModify
  appliesTo:
    - Server
  parameters:
     ...

apiVersion: core.oam.dev/v1alpha1
kind: Trait
metadata:
  name: Autoscaler
  annotations:
    version: v1.0.0
spec:
  stage: preStart/preModify
  appliesTo:
    - Server
  parameters:
     ...

[macolso]

Interesting idea! Could you create and link a PR with the schematic for this stage trait?

[wonderflow]

Sure, I'm glad to give one

[vturecek]

Is this field meant to be a hint to simplify implementations?

The only problem with this is that the trait resource is discoverable by users or tools, and this piece of information isn't really helpful to users or tools.

[xiang90]

We discussed about this inconvenience before. Basically traits implementation needs an easy to communicate with the runtime platform implementation. Probably putting the coordination information in the user facing Trait spec is not ideal. But I feel we need to have a standard or suggested way to make the coordination simple. Or this question will be asked by other OAM implementor.

[hongchaodeng]

I strongly agree with and support this feature. Based on my experience and feedback, our OAM users have two common use cases for ordering between trait and component:

• preComponentStart: Traits should be deployed before component be deployed. For example, we need to injecting/preparing configurations before component startup.
• postComponentStart: Traits should be deployed after component be deployed. For example, monitoring and health checking are deployed after component startup.

[vturecek]

@xiang90 just to clarify, because I'm hearing a couple different things here, you're saying this is a contract in the trait definition with the runtime implementation. That appears to be what @wonderflow is aiming for as well in #236 - a convenient place to store ordering information, rather than in some look-up table within an implementation.

While I agree it could be convenient for a runtime to be able to read the start-up order right from the trait spec, I think it would be awfully inconvenient if it turned out the start-up order defined by the trait didn't work for a particular runtime implementation. Start up order is runtime specific information. It's conceivable that two different runtime implementations may prefer different startup ordering for the same trait definition. The trait definition itself must be platform-agnostic.

@hongchaodeng it sounds like you might be saying something slightly different. You mention use cases for OAM users. Are you referring to end-users (app developers and operators) being able to control the start-up order of a trait? If so, that's a different discussion. It would be a change in the Application Configuration where an end-user applies the trait. I'm curious if there are specific cases when an app operator would need to control the start-up ordering for traits. I don't know of any.

[hongchaodeng]

Are you referring to end-users (app developers and operators) being able to control the start-up order of a trait?

It's neither. It is third party trait builders who just submit traits to the platforms.

Start up order is runtime specific information. It's conceivable that two different runtime implementations may prefer different startup ordering for the same trait definition. The trait definition itself must be platform-agnostic.

I think that's the key difference in our mental models -- whether runtime specific or not. But I actually think that this is also a good idea. Because this will simplify the OAM design and provide more flexibility in extension points.

[wonderflow]

Yeah, I agree start-up order should leave to runtime platform implementation.

Let me close this issue.