15 day public review for TOSCA Simple Profile in YAML Version 1.1 - ends March 2nd

["Mr. Jacopo Soldani" <jacopo.soldani@di.unipi.it>]

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