OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

tosca-comment message

[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>
Sent: Tuesday, March 1, 2022 12:52 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca-comment <tosca-comment@lists.oasis-open.org>
Subject: Re: [tosca-comment] RE: TOSCA workflows


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.




          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.









[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]