[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tosca-comment] RE: TOSCA workflows
|
Thanks Philippe, a couple of comments inline From: Philippe Merle <philippe.merle@univ-lille.fr>
Hi Chris, > Thanks Philippe. This approach could have value for Version 1.3, but would no longer work for Version 2.0 where TOSCA no longer defines
any normative types. Because of this: > > * The Version 2.0 language can no longer define any normative states Anyway our approach is independent from normative states, then could be applied to any state defined in any profile. > * In fact, the idea that there is a single state associated with a node does not work when you define multiple interfaces on that node.
The state machine associated with each interface should be treated separately. You are right: one unique management state does not work when a node has several management interfaces. > To deal with these issues, we have explored the following: > > * Associated a separate âstateâ attribute with each interface This seems interesting. But it is needed to define if the different state machines (a node instance has) are independent or if they need
to be coordinated. Yes, in general they may need to be coordinated. For example, a Backup interface may need the Lifecycle Management interface to be in a âmaintenanceâ or âofflineâ state before some operations can be called. I
think this can be handled using the same preconditions support mentioned below. > For the operations of an interface, define âpreconditionsâ that list the valid states in which the operation can be called, and âpostconditionsâ
that define the state into which the interface transitions when the operation succeeds. This seems right but it could be helpful to define the transitory state before executing an operation (e.g. starting before start) and the
state in case of operation execution errors. operations: start: source_states: [ created, configured ] # preconditions transitory_state: starting error_state: error final_state: started # postconditions This brings up another issue: TOSCA currently assumes synchronous operations, where operations could take a long time to complete. In such a scenario, a transitory state may be appropriate. However, if we introduced
an asynchronous mode of operation, then the transitory state could be handled using the previously suggested âpostconditionâ state (since the asynchronous operation presumably returns immediately), and then the state transitions again to the âpostâ operation
state after a notification of completion is received. Moreover it is needed to define the initial state of the state machine. Agreed, and we also need to specify how external operations on service topologies map onto desired state of the interfaces on the nodes and relationships in the topology.
> What needs to be investigated further is how interface operations on relationships interweave with interface operations on nodes. We need
language support for defining this as well. Yes there is a lot of works to do before obtaining a new satisfactory approach to precisely define the life cycle management of TOSCA nodes.
Anyway this is challenging. Yes, we welcome your ideas and suggestions. A+ Philippe Thanks, Chris |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]