Skip to content

Custom Invocation of Managed Workflows #1898

Description

@csviri

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:

 public UpdateControl<MyCustomResource> reconcile(MyCustomResource primary, Context<MyCustomResource> context) {
    simulateErrorIfRequested(webPage);
   
    // custom code before workflow execution

    context.managedDependentResourceContext().invokeWorkflow();
   
   // custom code after workflow execution
    
    return UpdateControl.patchStatus(primary);
  }

Probably would be nicer to do this just in some cases, so NOT require explicit invocation by default.

So such a feature flag could look like:

@ControllerConfiguration(
    workflow = @Workflow( 
          explicitInvocation = true,
          dependents = {
              @Dependent(...),
              @Dependent(...)}
    )
public class MyCustomResourceReconciler { }

see also related issue about naming: #1773

Activity

  1. added this to the 5.0 milestone on May 11, 2023
  2. linked a pull request that will close this issuefeat: introduce @Workflow annotation #2209on Jan 18, 2024
  3. metacosm commented on Jan 25, 2024

    @metacosm
    Collaborator

    Would it make sense to have pre- and post-reconcile workflows that would get executed before and after calling the main reconciler method, respectively?

  4. csviri commented on Jan 25, 2024

    @csviri
    CollaboratorAuthor

    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.

  5. csviri commented on Jan 31, 2024

    @csviri
    CollaboratorAuthor

    Typically this would be useful also to set some default values as discussed here:
    https://discordapp.com/channels/723455000604573736/723455000604573739/1201920896080543824

  6. csviri commented on Feb 5, 2024

    @csviri
    CollaboratorAuthor

    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.

  7. jcechace commented on Feb 28, 2024

    @jcechace
    Contributor

    What about making the @Workflow annotation 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.

  8. linked a pull request that will close this issuefeat: explicit workflow invocation #2289on Mar 13, 2024
  9. csviri commented on Mar 13, 2024

    @csviri
    CollaboratorAuthor

    I wonder if this is not misleading.

    context.managedDependentResourceContext().invokeWorkflow();

    Maybe should be:
    context.managedWorkflowContext().invokeWorkflow()

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions