User feedback about orquesta HOT 4 CLOSED

• Unit Testing -> Orchestra will be able to do multipoint inspection of syntax, expressions, and context/variables in a single pass on the workflow definition. It can also take mocked task outputs and conduct a mock run of the workflow definition. As comparison, Mistral can only find 1 error at a time and it cannot evaluate context/variables until runtime.
• Publish and reuse variable in the same task -> This sounds very useful. It's not possible with Mistral because publish is a dictionary and in python there is no sort order for dictionary items. So if Orchestra is to support this, the publish will have to become a list of single item dictionary.
• when condition in task and evaluated prior to task execution -> This should be feasible with Orchestra. I don't see any conflict in the underlying graph model of the workflow. We will need to explore how to implement it.
• Explicit main task / entry point -> There'll be other problems with this approach. The following will need to be considered before we can agree to implementing this.
  • For a workflow t1->t2->t3, what should happen to t1 if the entry point is explicitly marked t2? What if there are variables defined in the publish of t1 that t2 depends on?
  • For two branches t1->t2->t3 and t4->t5->t6, what should happen to the t4 branch if only t1 is specified as entry point?
  • For a join (visualize the letter y) where there are two starting tasks, what happens if only one of the task is specified as entry point?
• Linear execution by default -> tasks is a dictionary and in python there is no sort order for dictionary items. Therefore, with this data structure, we can't default to linear execution. What if we change tasks to list? It maybe possible but then for more sophisticated workflows with many tasks, branches, joins, error handling, etc, I think the list and default linear order will be hard to interpret. What we can do here is to make a short hand for on-success so there's less typing but still being as explicit as possible.
• Defined inputs and outputs -> Orchestra will keep these sections explicitly defined.
• Local variables in workflow -> Both Mistral and Orchestra has a vars section in the language to define local variables only visible within the workflow.

from orquesta.

Perhaps the execution models are defined not by an execution_model key, but by the data type of tasks. If tasks is a list, treat it like a linear action-chain style workflow. If it's a hash/dict it should use parallel execution and tasks must be explicitly linked together with next sections.

Defining an entry-point in the workflow itself doesn't sound interesting to me, other than maybe as the default workflow entry-point. But, specifying the entry-point via a workflow input parameter would enable targeting pieces of workflows. Sure, someone could split their workflows into additional workflows to be able to select just a few tasks in the workflow. But, if a few tasks break in a workflow, and the rest of the (ran in parallel tasks) completed, it would be nice to re-run just the branch of the task graph that failed. Maybe I forgot to add a key to the key-value store, or github was temporarily overloaded/unreachable when that task ran, or ... Re-run with a target entry-point would be fantastic.

from orquesta.

👍 to publish as a list
I can't tell you how many times I've tried this:

  publish:
    output: "{{ task('task1').result.stdout }}"
    # this errors out because output isn't available in the contex yet
    hello_world: "{{ _.output + ' world' }}"

and then done approximately this:

    publish:
      output: "{{ task('task1').result.stdout }}"
    do: finish_publishing
finish_publishing
  action: noop
  next:
    publish:
      hello_world: "{{ _.output + ' world' }}"

👍 to when conditions

💯 for Orchestra ;)

from orquesta.

We will close this issue here as this is for general user feedback during alpha/beta. If there are specific feature request or problem with orquesta, please open a separate issue for each.

from orquesta.