I forgot to mention the Custom Workflows wiki: https://cwiki.apache.org/confluence/display/ARIATOSCA/Custom+Workflows
On Wed, Aug 2, 2017 at 2:11 PM, Tal Liron <[email protected]> wrote: > 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? >
