You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 8, 2022. It is now read-only.
When we create an AppConfig, using dependency feature like below, the component will rely the output of echo trait, and binding the data into field spec.fieldA.
Everything works well at first creation. OAM runtime will wait the status of trait CR to be ready, and after that pass the value abc into workload spec.fieldA.
In day 2, when we update the AppConfig, changed the spec, for example, change the data field from abc to xyz, and leave the other fields as they are.
The bug come out: the value of workload in spec.fieldA is still abc, nothing changed.
After digging the problem, I find out that, when we update the trait CR, before the controller observed, the status is already in ready=true state.
OAM lacks of mechanism to indicate whether workload/trait CR is successfully observed by its controller.
So when an AppConfig CR is updated, we can't confirm whether the update is resolved(by workload/trait controller) or not. So the status results in our case are also unreliable.
OAM runtime can compare the value of status.observedApp with AppConfig labels.oam-app-hash. There are two ways to check this mechanism.
Solution 1: always check status.observedApp in dependency, if this field not exist, ignore it, if this field exist but not match, regard it as condition not match.
Solution 2: Add valueFrom fieldPath for datainput/output condition, let oam-runtime check that value from metatdata.label should equal to status.observedApp
I will fix the issue as soon as I can. Will pull up a PR in about two days.
The fix will be based on observed generation and will put a generation label into Workload/Trait CR.
hongchaodeng
changed the title
[BUG] dependency won't work as expected in updating
Adding observed generation to prevent passing the old data
Jul 4, 2021
Problem Background
When we create an AppConfig, using dependency feature like below, the component will rely the output of
echo
trait, and binding the data into fieldspec.fieldA
.Everything works well at first creation. OAM runtime will wait the status of trait CR to be ready, and after that pass the value
abc
into workloadspec.fieldA
.In day 2, when we update the AppConfig, changed the spec, for example, change the data field from
abc
toxyz
, and leave the other fields as they are.The bug come out: the value of workload in
spec.fieldA
is stillabc
, nothing changed.After digging the problem, I find out that, when we update the trait CR, before the controller observed, the status is already in
ready=true
state.OAM lacks of mechanism to indicate whether workload/trait CR is successfully observed by its controller.
So when an AppConfig CR is updated, we can't confirm whether the update is resolved(by workload/trait controller) or not. So the status results in our case are also unreliable.
This is a little like K8s observedGeneration mechanism, and I used to raise an issue to add observedGeneration for AppConfig and Component CR.
While
observedGeneration
is not enough. Like the picture below, theobservedGeneration
can't ensure workload/trait reconciled successfully.Proposal
So I propose to add a mechanism here, the overall idea is to let oam-runtime know whether the latest version of workload/trait is observed/reconciled.
oam-app-hash
and propagate as label into trait and workload CR.status.observedApp
with AppConfiglabels.oam-app-hash
. There are two ways to check this mechanism.status.observedApp
in dependency, if this field not exist, ignore it, if this field exist but not match, regard it as condition not match.valueFrom fieldPath
for datainput/output condition, let oam-runtime check that value from metatdata.label should equal tostatus.observedApp
@hongchaodeng Would you like to fix this issue?
\cc @ryanzhang-oss @resouer
The text was updated successfully, but these errors were encountered: