tosca message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [tosca] 15 day public review for TOSCA Simple Profile in YAML Version 1.1 - ends March 2nd
- From: "Matt Rutkowski" <mrutkows@us.ibm.com>
- To: "Mr. Jacopo Soldani" <jacopo.soldani@di.unipi.it>
- Date: Wed, 1 Mar 2017 12:27:20 -0600
Hi Jacopo,
Thanks for your thoughtful comments.
Indeed, the Simple Profile WG has considered
and discussed the possibility of "state injection" as part of
sub-classing the normative lifecycle interface to allow new operations
(representing new states) to be added between standard operations with
associated artifacts for implementation of the state change (which would
be the path forward). However, for v1.1 we decided that support of
declarative workflow (allowing for a task based, grammar to inject complex
state transitions even spanning nodes) was the more important use case
to tackle. Have you looked at v1.1 workflow which may be able to
achieve/solve the use cases you propose? It would be good to isolate
your use case if possible to something that may not be achievable via the
workflow grammar and we would then perhaps pursue for v1.2 or v1.3 as a
new feature.
Kind regards,
Matt Rutkowski
STSM, Master Inventor, IBM Open Cloud Technologies
and Standards
Apache OpenWhisk Incubator Project Lead,
Initial Committer
Chair, Lead Editor OASIS TOSCA Simple Profile
WG,
Co-Chair OASIS TOSCA Interop. SC,
Founder of DMTF Cloud Audit (CADF) Standard
mrutkows@us.ibm.com, mobile: 512-431-5002
From:
"Mr. Jacopo Soldani"
<jacopo.soldani@di.unipi.it>
To:
tosca@lists.oasis-open.org
Date:
03/01/2017 02:30 AM
Subject:
[tosca] 15 day
public review for TOSCA Simple Profile in YAML Version 1.1 - ends March
2nd
Sent by:
<tosca@lists.oasis-open.org>
Hi all,
The current version of TOSCA does not permit customising the lifecycle
of a single component. The declarative processing of a node is always the
same, while by even only restricting to the standard lifecycle interface
one may experience different behaviour of components (e.g., ?configure?,
which may be used to configure a component at runtime, while another may
require to be configured before being actually started).
TOSCA node types can be described by means of their states, requirements,
capabilities, and management operations, but there is currently no way
to specify how management operations affect states, how operations or states
depend on requirements, or which capabilities are concretely provided in
a certain state. The absence of a ?management behaviour description?
implies that it is not possible to automatically check whether a workflow
is valid, or even to automatically derive workflows capable of reconfiguring
a TOSCA application by reaching desired goals.
We hence believe that TOSCA should permit specifying the management behaviour
of the nodes in a topology (at a type level), by allowing to indicate in
which states an operation can be executed, and which are its effects. Of
course, to simplify the specification of an application, and to ensure
backward compatibility with previous versions of TOSCA, the default lifecycle
could be used if no other behaviour is specified.
Also, we believe that the management behaviour of a node should be specified
by means in a simple, modular and compositional way, e.g., by means of
a finite state machine (as in management protocols [1]):
management_protocol:
initial state: <state_name>
state_assumptions:
<state_name>: [<list_of_needed_requirements>]
<state_name>: [<list_of_needed_requirements>]
?
state_offerings:
<state_name>: [<list_of_needed_requirements>]
<state_name>: [<list_of_needed_requirements>]
?
transitions:
transition:
source_state: <state_name>
target_state: <state_name>
operation_name: <operation_name>
interface_name: <interface_name>
requires: [<list_of_requirements>]
This would permit declaratively processing components, also in presence
of management operations that do not appear in the normative lifecycle
interface tosca.interfaces.node.lifecycle.Standard. For instance, one could
automatically determine the workflows to execute to deploy or undeploy
an instance of a topology template (as well as worflows permitting to reach
other goals). One could also validate workflows that she included in her
topology template.
Our 2 cents.
Thanks a lot,
Antonio Brogi and Jacopo Soldani
Computer Science Department, University of Pisa
[1] Brogi A., Canciani A., Soldani J. (2015) Modelling and Analysing Cloud
Application Management. In: Dustdar S., Leymann F., Villari M. (eds) Service
Oriented and Cloud Computing. Lecture Notes in Computer Science, vol 9306.
Springer
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]