[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: question about TOSCA workflows
|
More questions about TOSCA workflows:
1.
I’d still like opinions on my proposal (stated below) to make node states interface-specific. This would allow each Interface type to define its own set of valid node state values, which would allow
us to validate whether state values used in workflows are valid.
2.
Section 7.2 discusses “weaving”: the interleaving of Lifecycle operations of relationships with the Lifecycle operations of the nodes at the source and the target end of those relationships. However,
this interleaving was already discussed in Sections 5.8.4 and 5.8.5 where the normative interface types are introduced, so there seems to be some redundancy. More importantly, the “weaving” information in Section 7.2 is inconsistent with the sequence diagrams
specified in Section 5.8, so the document has conflicting information about the correct way to interleave lifecycle management operations. These two sections need to be reconciled (and redundancies removed).
3.
It appears that the document doesn’t discuss weaving when a node has multiple requirements (which would result in multiple relationships). Given that requirements (and their associated relationships)
are ordered, it is clear which relationship needs to be “configured” first. However, it isn’t entirely clear at what point it is “safe” to start configuring the second, third, etc. relationship. Does the Configure lifecycle for the first relationship need
to be completed in its entirety (i.e. all the way through the “add_target” operation) or is it OK to start the Configure lifecycle of the second relationship at some earlier point (e.g. right after the post_configure_source and post_configure_target operations)? Thanks, Chris From: Chris Lauwers In my opinion, we shouldn’t allow states that the orchestrator doesn’t know about. If we support arbitrary states, then a custom workflow could leave a node in a Lifecycle Management state from which it might
not be able to recover (since presumably the orchestrator only knows about the “normative” states and won’t know what to do with nodes that aren’t in any of those states).
After thinking about this more, I believe the real issue here is that we’re overloading the “node state” for different (unrelated) uses. The normative node states in the current version of the specification are
really “lifecycle management states”: they are only relevant in the context of the Standard Lifecycle Management Interface (and they sort of drive the lifecycle management state machine). The workflow examples in the specification try to re-use this “lifecycle
management state” variable to drive the state machine for a Backup Interface, which arguably doesn’t have much (if anything) to do with lifecycle management. What would be really helpful is to have a separate “backup management state” that’s different from
the “lifecycle management state”. That would avoid the need for “non-standard” lifecycle management states. What this suggests, then, is that there is a need for a separate “node state” associated with each Interface: the Lifecycle Management Interface has a node state, but so does the Backup interface. This could
easily be accomplished by moving the node state property from Node objects into Interface objects, meaning that each Interface Type would define its own node state. In the process of defining the Interface node state, Interface Types would also specify the
“valid values” for this node state in the context of the Interface, which would allow a validator to check any workflows (or imperative policies) that use these node states. This would also support “custom” lifecycle management interfaces that introduce lifecycle
management states that are different from those supported by the normative Standard Lifecycle Management interface. If we adopt this approach, then obviously the “set_state” activity in custom workflows needs to specify not just the state value, but also the Interface to which the state belongs. Thanks, Chris From: BOUTIER, LUC [mailto:luc.boutier@fastconnect.fr]
Hi Chris, If this is just grammar elements I guess they can be fixed, just keep a track of the changes in the doc maybe so people can review it (more to see what was wrong). Question about set_state is interesting, I guess that right now the states an orchestrator knows and can handle on its own are the one specified in TOSCA spec 3.3.1. That said I don’t think it is invalid to set a custom
node state, as we can define policies that react to any attribute, we can create policies that react to a custom node state. I would just put as a warning to such usage that if a user adds a custom state he should know that the orchestrator won’t understand this state and that resolution of potential unknown states will have to be done through
custom logic (custom workflow to trigger, custom policy etc.). Luc From: Chris Lauwers <lauwers@ubicity.com> After implementing TOSCA workflows, I noticed a number of things in the spec that may need further clarification and/or correction. Specifically, most of the workflow examples in section 7.3 contain grammar that doesn’t
quite jive with the spec. Is it OK if I go ahead and fix those in 1.2 or do we need a more formal process? Also, question about the “set_state” keyname in the Workflow Activity Definition (Section 3.5.17.1). Is the intent here that the only node states that can be used here are the “node states” as defined in Section 3.3.1?
If not, how do we check if specified node states are valid? Thanks, Chris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]