Loop control in workflows

[dustinblack]

Please describe what you would like to see in this project

Workflows need the ability to execute plugins, groups of plugins, or other nested workflows in loops based on variable input to the workflow schema or other logic.

Please describe your use case

In the simplest case, a workload plugin may need to run multiple samples with the same parameters. In more complicated cases, a workload plugin may need to be run many times over with a multi-dimensional graph of parameters. There may also be related parallel plugins that at minimum need to update some metadata context as part of a loop cycle

Additional context

Running benchmarks or other load generators as plugins necessitates the collection of multiple samples of a configuration for data integrity. We also typically want to collect data for the same SUT (system under test) for various related but different test conditions. For instance, we may want to run uperf with multiple protocols, multiple packet sizes, and multiple traffic patterns, creating at minimum a 3-dimensional graph of required tests plus loops of each individual test for multiple samples.

[hubeadmin]

From an automotive perspective:

Loop control would be very useful to offload the conditional "wait" logic to the framework, rather than having it be in code.

The main use case for us is when we need to do a pretty long wait, until our package build system brew/koji finally makes its way through its work queue and reaches our request to add a new package to a tag. This can sometimes take 30–60 minutes from the time we originally submit the request, keeping the plugin alive for this period of time seems pretty wasteful. The engine itself could automatically reschedule the plugin to run in N minutes as defined by some control parameter, or probably closer to what you're thinking, an expression in the workflow rather than having to occupy the container system (k8s or podman or whatever) until it's finally satisfied with the output of the plugin. (Here, we don't want to consider the plugin as failed unless an actual error gets thrown up)

As of now, the automotive design makes use of the wait in code, because it isn't present in the framework. So this isn't a massive issue, but it would be a pretty nice feature to have, to stop excessive resource hogging.

The example that Dustin gave in the description, is also applicable for automotive.
But in our context we will want to run the same tagging process plugin, but for each new package that we retrieve from our upstream product definition (it can be 1, but also can be 20). Again, this isn't a massive blocker because we can deal with it at the plugin level with code, but would be a really neat feature to have as part of the framwork itself.

[ghost]

#32 implements the main component of this issue by separating the step execution from the main engine loop. This way the main engine loop can be embedded as a step, for example to execute subworkflows. Subworkflows in turn mean, that a loop can be implemented.

[ghost]

PR #71 is now ready for review.