Ryan Zhang

> ```yaml > package: # the encapsulation of this component. alternative name: module, componentSpec, encapsulation, templateModule, schematic > ``` I vote for "schematic"

Thanks, Haishi. We (Alibaba) already used OAM to describe upgrade/rollback. In our practice, we apply a trait to a component in a declarative way similar to what you described here....

> or OAM to have value that is broadly applicable to everyone, we have to provide common abstractions and concepts as the OAM model itself. Otherwise, we have an model...

> Rolling updates or canary deployments involve multiple versions of an app/component. How do you apply a trait to multiple version of the same component? That's the reason we are...

> Hey @ryanzhang-oss, can you please provide an example of a trait describing rolling update or canary deployment? It will help me to understand how you envision to express such...

I think the bug is that a trait acts without any context in the current rudr implementation. Each trait's action is pre determined regardless of the component it applies to....

Another thing is that the the spec didn't say what happens when there are multiple containers/volumes in the component so it's probably not a good example. We should remove the...

> ^ agree. Just out of curiosity, what is the "new OAM go implementation" you referred to? Is it the same as the `oam-go-sdk`? It's not the same but it...

The traits in the spec is already an array. IMO, an array of array is not desirable. It seems that users can apply multiple traits of the same type to...

Thanks Abelard. I think we will incorporate this into our new spec. However, I wouldn't say it's a new workloadType but more like a new group/category of workloadType.