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
In some use cases it would handy to implement custom code before the managed workflows executes, see for example: #1896
Currently the managed workflow always execute before the reconcile(...) method automatically. What we could provide is a method invoke the managed workflow:
publicUpdateControl<MyCustomResource> reconcile(MyCustomResourceprimary, Context<MyCustomResource> context) {
simulateErrorIfRequested(webPage);
// custom code before workflow executioncontext.managedDependentResourceContext().invokeWorkflow();
// custom code after workflow executionreturnUpdateControl.patchStatus(primary);
}
Probably would be nicer to do this just in some cases, so NOT require explicit invocation by default.
Would it make sense to have pre- and post-reconcile workflows that would get executed before and after calling the main reconciler method, respectively?
Not sure how the user would then update the status, based on the results of the flow after the second workflow. Was thinking on other variants also, like having a list of managed workflows.
But would not complicate it, there are still standalone workflows for complex use cases. And usually I guess users have a set of resources they want to reconcile, with custom invocation we give possibility to check the precondition / pre-processing and set the status after, this is both general and powerful enough.
Note that this is little bit more cumbersome for cleanup, if Cleaner interface is not implemented probably should be called implicitly even the flag is there (when not all dependents are garbage collected), if cleaner is implemented it should be called explicitly when the flag is on.
Activity
metacosm commentedon Jan 25, 2024
Would it make sense to have pre- and post-reconcile workflows that would get executed before and after calling the main reconciler method, respectively?
csviri commentedon Jan 25, 2024
Not sure how the user would then update the status, based on the results of the flow after the second workflow. Was thinking on other variants also, like having a list of managed workflows.
But would not complicate it, there are still standalone workflows for complex use cases. And usually I guess users have a set of resources they want to reconcile, with custom invocation we give possibility to check the precondition / pre-processing and set the status after, this is both general and powerful enough.
csviri commentedon Jan 31, 2024
Typically this would be useful also to set some default values as discussed here:
https://discordapp.com/channels/723455000604573736/723455000604573739/1201920896080543824
csviri commentedon Feb 5, 2024
Note that this is little bit more cumbersome for cleanup, if
Cleanerinterface is not implemented probably should be called implicitly even the flag is there (when not all dependents are garbage collected), if cleaner is implemented it should be called explicitly when the flag is on.jcechace commentedon Feb 28, 2024
What about making the
@Workflowannotation a top level and directly appleid to the Reconciler?IMHO this would improve readability as personally I'm not a fun of overusing nested annotations.
csviri commentedon Mar 13, 2024
I wonder if this is not misleading.
context.managedDependentResourceContext().invokeWorkflow();Maybe should be:
context.managedWorkflowContext().invokeWorkflow()