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

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


It I remember correctly, Antonio Brogi, on some TOSCA WG call some time back mentioned this paper (or possibly a related one) with a scheme to completely specify the conditions of all management operations in lifecycle extensible way. The discussion back then is that TOSCSA could explicitly encode this. We acknowledged it was not expressible yet in TOSCA. I also remember it mentioned that not just requirements, but state variables (all attributes not just the “orchestration state”) of the target node instances need to be considered, which is the most general approach.

 

Derek

 

From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] On Behalf Of BOUTIER, LUC
Sent: Wednesday, March 1, 2017 10:53 AM
To: Matt Rutkowski <mrutkows@us.ibm.com>; Mr. Jacopo Soldani <jacopo.soldani@di.unipi.it>
Cc: tosca@lists.oasis-open.org
Subject: Re: [tosca] 15 day public review for TOSCA Simple Profile in YAML Version 1.1 - ends March 2nd

 

Hi Matt, Jacopo,

 

I’m quite interested by Jacopo early proposal. Even If this may require further discussions indeed on how it fits with workflows an policies. I see that maybe as another proposal for 7.4. to define advanced workflows or/and policies.

 

Let’s see how/when we can discuss that…

 

Luc

 

From: <tosca@lists.oasis-open.org> on behalf of Matthew Rutkowski <mrutkows@us.ibm.com>
Date: Wednesday, 1 March 2017 at 19:27
To: "Mr. Jacopo Soldani" <jacopo.soldani@di.unipi.it>
Cc: "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Subject: Re: [tosca] 15 day public review for TOSCA Simple Profile in YAML Version 1.1 - ends March 2nd

 

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]