[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tosca-comment] RE: TOSCA workflows
> 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.
> 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.
A+
Philippe
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:
To deal with these issues, we have explored the following:
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.
Thanks,
Chris
From: Philippe Merle <philippe.merle@univ-lille.fr>
Sent: Monday, February 28, 2022 12:35 PM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: tosca-comment <tosca-comment@lists.oasis-open.org>
Subject: Re: TOSCA workflows
Hi Chris,
> I'm curious about your use case for imperative workflows.
We are developing a tool to verify imperative workflows and detect behavioural bugs, e.g.
workflows:
deploy:
steps:
deploy_x:
target: x
activities:
- set_state: creating
- call_operation: Standard.create
- set_state: starting
- call_operation: Standard.start
This previous sequence of activities could be considered as incorrect as some activities are missing, i.e.: set_state: created and set_state: started
activities:
- set_state: creating
- call_operation: Standard.create
- set_state: created # missing
- set_state: starting
- call_operation: Standard.start
- set_state: started # missing
To validate this tool, we are currently generating both correct and incorrect imperative workflows automatically.
But to go a step beyond, we are searching concrete imperative workflows.
> We have had discussions about removing support for imperative workflows from the language and
This will be a big feature removal!
But the removal could be justify if no TOSCA orchestrator implements imperative workflows.
> generalizing support for declarative ("automatically generated") workflows.
We are developing a generator to automatically generate imperative workflows from a topology template.
> We have also looked at supporting a more general "state/event" model where topology-wide behavior "emerges" as a result of state/event transition tables defined locally on each node and/or relationship.
In our approach, we are defining a finite state machine where transitions are labelled by workflow activities (e.g. set_state: created, call_operation: Standard.create).
A+
Philippe Merle
De:
"Chris Lauwers" <lauwers@ubicity.com>
Ã: "Philippe Merle" <philippe.merle@univ-lille.fr>, "tosca-comment" <tosca-comment@lists.oasis-open.org>
EnvoyÃ: Lundi 28 FÃvrier 2022 20:54:20
Objet: RE: TOSCA workflows
Hi Philippe,
I'm curious about your use case for imperative workflows. We have had discussions about removing support for imperative workflows from the language and generalizing support for declarative ("automatically generated") workflows. We have also looked at supporting
a more general "state/event" model where topology-wide behavior "emerges" as a result of state/event transition tables defined locally on each node and/or relationship.
Thanks,
Chris
-----Original Message-----
From: tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org> On Behalf Of Philippe Merle
Sent: Sunday, February 13, 2022 6:39 AM
To: tosca-comment@lists.oasis-open.org
Subject: [tosca-comment] TOSCA workflows
Hello,
I am conducting a research work around TOSCA imperative workflows.
Could one point me to freely available TOSCA imperative workflow examples?
Which TOSCA orchestrators could execute TOSCA imperative workflows?
Thank you in advance for your replies.
Philippe Merle
Inria researcher
--
This publicly archived list offers a means to provide input to the OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC.
In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting.
Subscribe: tosca-comment-subscribe@lists.oasis-open.org
Unsubscribe: tosca-comment-unsubscribe@lists.oasis-open.org
List help: tosca-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/tosca-comment/
Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tosca
Join OASIS: http://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]