> > 1) Is it possible to send me an example of a custom workflow graph? >
There is a rather simple one here: https://github.com/apache/incubator-ariatosca/tree/master/tests/resources/service-templates/tosca-simple-1.0/node-cellar On the YAML side, you'll see how we use the aria.Workflow policy type to link the workflow function. In this example, we're deriving the type in order to add an extra property, but you can also use the aria.Workflow type directly if you don't need to extend it. Then, in workflows.py you will see the actual Python function that builds the task graph. It's a very trivial one in this case: we simply go through all nodes and try to create a task to execute the operation. Nodes that don't have the interface/operation will raise an exception, so we just ignore those and move on. The task graph API is much richer and allows complex interdependencies. At this point I don't think we have a good example for more complex workflows. 2) When executing an operation associated with a "script", what are the > main implications or differences between executing a Juju charm vs > executing a shell script. > > Is it something like this? > > - a shell script is an artifact that is included in the CSAR and is likely > executed by the local TOSCA ARIA orchestrator > > - a juju charm is not an artifact (therefore not included in the CSAR) and > is likely executed by a remote Juju service orchestrator > It's not just a shell script -- it would be any OS executable. It could be a shell script, or a Python script, or an .exe, etc. You are right about Juju not being an artifact. This is why I am arguing against the current idea on the table for TOSCA 1.2 to support more complex operations using artifacts: a charm is just not an artifact. It should be, in my opinion, solved by new operation types. Until then, ARIA "solves" the situation by allowing for plugins that would provide their own execution of the operation. We don't have a Juju plugin right now, but I think it would not be hard at all to create one. It's something you can contribute! > 3) Is it possible to create custom node states using TOSCA/ARIA? > ARIA does not currently allow for this, because TOSCA doesn't. So we indeed validate that the state you set is one of the currently supported states. (Actually there is one extra state that ARIA adds internally, but in any case a user can't simply add one.) A workaround is to use a custom node attribute instead. You can then set this "state" attribute to anything you wish. Operations can set this attribute using ctx. So in a bash script it would like this: ctx node attribute state = my-custom-state More about using ctx: https://cwiki.apache.org/confluence/display/ARIATOSCA/Execution+Context The downside is that you would have to declare this attribute at the node type level, so it won't work with built-in nodes unless you derive from them. 4) Also related to node states. It looks like the YAML specs has a couple > of discrepancies for the normative uninstall workflow (section 5.7.4.4.2 in > YAML 1.0). > > IMO the available state is not defined and the diagram at the top of the > workflow should use the started state instead. > > IMO the configured state at the bottom of the workflow diagram should be > replaced with the initial state instead. > > Do you agree? > I agree. :) The spec actually only really discusses the install workflow, not the others, and even with install it has two separate diagrams that contradict each other. Changing the node state is currently handled in ARIA via event listeners: certain kinds of tasks trigger events that cause the state to change. The mechanism is currently a bit opaque and not very easy for users to extend. Perhaps other ARIA committers can comment more about it?
