-
Notifications
You must be signed in to change notification settings - Fork 216
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: explicit workflow invocation uses the same resource intance that reconcile api #2686
Conversation
… reconcile api Signed-off-by: Attila Mészáros <[email protected]>
Signed-off-by: Attila Mészáros <[email protected]>
Signed-off-by: Attila Mészáros <[email protected]>
@@ -116,4 +116,8 @@ public DefaultContext<P> setRetryInfo(RetryInfo retryInfo) { | |||
this.retryInfo = retryInfo; | |||
return this; | |||
} | |||
|
|||
public P getPrimaryResource() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a big fan of exposing this method only for tests…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for jumping in here, but if this method is not exposed, how a main reconciliation loop will be aware that the primary resource has changed if in the middle of one reconciliation an explicit dependent resource reconciliation is requested via context.managedWorkflowAndDependentResourceContext().reconcileManagedWorkflow();
It may happen that the primary resource is updated, or either its status, and then the main reconciliation loop will not be using a most up to date version of the primary resource. Or am I wrong?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afalhambra-hivemq usually you get this as a parameter for example here for dependent resources:
Line 254 in 1e3ac83
protected R desired(P primary, Context<P> context) { |
It is not part of the interface (Context) just the impl so it is unit testable but you never access this primary resource through this method. I think @metacosm has a point I'm not big fan either, but on the other hand if there is no other way to unit test it I prefer to be just pragmatic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's the intent here, though. Also, the primary should probably not changed during a reconciliation loop but be the target of a subsequent reconciliation because otherwise the current one might be operating on inconsistent basis (for example, some dependents might have seen the old primary version and taken decisions based on that, while others might see a new, possibly contradictory version…)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you use SSA should not change, otherwise fine. We should explain that in docs maybe more thoroughly or in a separate blogpost.
Will expand that section in release blogpost (currently there is a TODO 😶🌫️ )
Signed-off-by: Attila Mészáros [email protected]