[Feature]: Allow more customization of when a workflow can (or can't) be run

[crankynetman]

Contact Details

[email protected]

What should we build?

Today, with the WFO, lifecycle state of a product or product block (Inactive, Provisioning, Active, Terminated, etc.) is more geared toward whether or not a workflow can be run safely (i.e. are there other workflows in flight, is it referencing something that doesn't exist anymore, etc.).

This can be customized using the WF_USABLE_MAP variable and the UI only shows workflows that can be run at that time. This works quite well, however, it would be really interesting and useful to be able to define more complex logic around when a workflow should or should not be run, not so much from a WFO integrity standpoint, but more from a business logic standpoint.

User Stories:

• As a user of the WFO, I would like to be able to "grey out" a workflow based off of non-lifecycle state attributes.
• When defining the logic of what makes a workflow valid to be run from a business logic standpoint, I would like to be able to write python code.
• I would like to define this logic in the workflow definition itself.

Example Code:

Given this StepList on a workflow:

@modify_workflow("Modify node", initial_input_form=initial_input_form_generator)
def modify_node() -> StepList:
    return (
        begin
        >> set_status(SubscriptionLifecycle.PROVISIONING)
        >> update_subscription
        >> update_node_in_ims
        >> update_node_in_nrm
        >> set_status(SubscriptionLifecycle.ACTIVE)
    )

It would be nice to then be able to define a function that the tells the API and frontend if this workflow should be allowed to run, for example like this perhaps in the workflow file:

def enable_node_modify(subscription, error_message="This workflow can't be run until something else has happened") -> bool:
    if subscription.my_special_field == "my_special_value_that_means_we_can_run_this":
        return True
    else:
        rase ValueError(error_message)

Then, if my_special_field is set properly, the function returns True and the API and frontend know that the user can run this workflow (it will be visible in the "Actions" menu). If my_special_field is not set to what we want it to, then the function returns False and the workflow is greyed out in the "Actions" menu and the error_message value is also displayed (so a user of the WFO can know what they need to do to enable that workflow).

This would be added to the steplist like so:

@enable_workflow(enable_node_modify) # This function must only return true/false
@modify_workflow("Modify node", initial_input_form=initial_input_form_generator)
def modify_node() -> StepList:
    return (
        begin
        >> set_status(SubscriptionLifecycle.PROVISIONING)
        >> update_subscription
        >> update_node_in_ims
        >> update_node_in_nrm
        >> set_status(SubscriptionLifecycle.ACTIVE)
    )

Obviously this is a pseudocode and more thought would need to be put into this, but I'm curious if this would be of interest to others. Thanks!

Relevant pseudo code

No response

[tjeerddie]

details aside, It would be cool to have.

We have worked around this by using form validation and workflow steps to first check if a resource type has the correct value.
Another not so optimal way to work around this is overriding the subscription_workflows_by_id endpoint that returns the workflows (with reasoning if it can't be run) with additional workflow checks.

[crankynetman]

We do the same with form validation for sure. It works, but it does require the user to "start" the workflow and then get very disapointed when they can't do what they thought they could.

I like the subscription_workflows_by_id workaround, I might try playing with this if I can find some spare time, as it could clue me in on how to start an implementation of this FR.