TOSCA Simple Profile for YAML: Changes proposed for 1.3 release Claude Noshpitz Presentation to OASIS TOSCA Technical Committee December 13, 2018

Areas of focus Clean up ambiguities and inconsistencies from prior spec releases Flesh out operational capabilities to facilitate “real-world” use Support ETSI-NFV, ONAP More robust spec documentation, including examples cleanup

Some new things Asynchronous notifications (based on Calin’s latest document, which removes asynchronous operations) Support for 3rd-party workflows (based on Thinh’s proposal, but with support added for “outputs”) Artifact properties (based on Priya’s contribution that clarifies where and how to use artifact properties) Additional constraint logic (based on Anatoly’s proposal). Remove any HPA examples from spec – lacking agreement on use in this way Potential for a distinct Profile capturing HPA, for importing as needed?

Details Clarify abstract/substitution semantics Notification interface Advanced condition/constraint syntax for filtering, matching Normative properties on Artifacts Artifact types (in flight) Consistency across capability/requirements/filtering syntax, list types Advanced filtering syntax Input values on operations and workflows Consistency in type extension semantics (property assignment changes) Custom declarative workflows Multiple entry points in a CSAR Clarifications on get_input semantics

Notification semantics The notification concept gives a formal way to connect a) external object information to TOSCA node attributes and b) outside events to TOSCA orchestrator events (that can trigger policies and other workflows). This is filling a gap on how a TOSCA model information follows the changes in the real world it models. The proposal is intuitive w.r.t. existing operation definition and integrates well within the same interface.