ariatosca-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tal Liron <...@cloudify.co>
Subject Re: Workflow graph, Juju charm and node states
Date Wed, 02 Aug 2017 20:59:24 GMT
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 <tal@cloudify.co> 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?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message