component should be mutable in alpha2 #343
Conversation
hongchaodeng
requested review from
resouer,
technosophos and
vturecek
as code owners
| @@ -33,7 +33,7 @@ In addition, as an application configuration is released, its _component instanc | |||
|
|
|||
| To accommodate this definition of a release, an OAM platform SHOULD make the following assumptions: | |||
|
|
|||
| - A component (as defined in the [component model](4.component.md) section) is immutable. It should not be changed after creation. | |||
| - A component (as defined in the [component model](4.component.md) section) is mutable. Upgrade can happen by updating the component, e.g. updating image. | |||
There was a problem hiding this comment.
Should merge this paragraph with the paragraph below, because change on a Component will results a new release.
|
If we mutate a component any existing workload that uses that component will be updated. Is that really what we want? I don't have a strong opinion either way, but it would be very helpful to explain why this change is being made in the PR. |
|
@negz What will be the My current thought is yes, update Component should trigger rollout of the application by following strategy defined in rollout Trait (if defined). |
|
In the view of OAM runtime builder, if component is mutable, then component change should trigger AppConfig Controller to reconcile the application(how to reconcile/rollout is another story). This may add complexity to OAM runtime, but I think it could work. In this case we may need to add component version automatically in runtime, like revision in K8s object. |
|
Please take a look at #336 which is very much related to this. |
|
LGTM |
No description provided.