Enhancements for Simple YAML Profile v1.2 April 3, 2017 Thinh Nguyenphu, Nokia, thinh.nguyenphu@nokia.com Prabakaran Venugopal, Nokia, prabakaran.venugopal@nokia.com Moshe Elisha, Nokia, moshe.elisha@nokia.com

Adding metadata to parameter definition (see Simple YAML v1.1: section 3.5.12.2) Goal – Store arbitrary information on an parameter. Use case - Protect sensitive information (such as passwords) when user keying in GUI or group inputs together in GUI systems. Proposal – Add optional “metadata” keyname to parameter / input definition. Note: TOSCA implementers can decide on some keys to have special unified meaning across implementations inputs:   pin_code:     type: integer     description: 4 digits PIN code     constraints:       - in_range: [ 1000, 9999 ] metadata: # Arbitrary key value map masked: true group: common

Support generic data structures See Simple YAML v1.1: section 3.2 (Parameter and property types) Goal - Support generic / unknown / complexed data structures for better integration with external systems. Use cases Expose a parameter that is simply passed as is to underlying layers (for example, Heat supports the “json” parameter data type). Allow reading unknown data structures from external systems (for example, using “get_operation_output” from a workflow output). Proposal – Add “json” as a valid data type for input / property / attribute. inputs: fw_server_metadata: type: json Note: This enhancement is already existed in Heat template https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#parameters-section Heat Orchestration Template - Parameter section

See Simple YAML v1.1: section 3.5.12.2 and 3.5.2 Validate JSON values See Simple YAML v1.1: section 3.5.12.2 and 3.5.2 Goal – Enforce a certain schema / structure on JSON type inputs / properties / attributes Use case – Passing a metadata object with certain rules and structure that describes a VM expiration policy. Proposal – Add “schema” as a valid constraint type (applicable for JSON data type). inputs: metadata: type: json constraints: - schema: { "properties": { "expiration": { "type": "integer", "minimum": 0 }, "action": { "enum": [ "stop", "terminate" ] } "required": ["expiration"]

Support custom constraints See Simple YAML v1.1: section 3.5.2 (Constraint Clause) Goal – A way for the author to define a custom logic that will validate values Use cases Validate that a value against dynamic valid values Add a constraint logic that does not exist (for example, “prime numbers”) Proposal – Add “custom” as a valid constraint type. The “my_int” value will be passed to prime_constraint.sh as an argument and the script will exit with exit code of zero if the value is a prime number. inputs: my_int: type: integer constraints: - custom: prime_constraint.sh

Control operation executions See Simple YAML v1.1: section 3.5.14 (Interface Definition) Goal – An easy mechanism to handle interface operations failures Use case – Loops waiting for resources (Like waiting for SSH on a VM) Proposal – Add “timeout” and “retry” keynames to interface operation. node_templates: my_node: ...     interfaces:       Standard:         create:           implementation: change_hostname.sh           timeout: 500 # timeout in seconds for each iteration retry: # Retry 5 times with 30 seconds delay delay: 30 count: 5

Assigning attributes values after operation execution See Simple YAML v1.1: section 3.5.14 (Interface Definition) Goal – Assign values to attributes after a successful operation execution Use cases Assigning an operation output in an attribute for easy access Creating a Nuage managed network in OpenStack that requires a Nuage subnet and a Neutron network Proposal – Add “assign” clause to allow setting attributes. Read the assign section as follows: “After executing implementation, assign the value <value> into attribute <attribute_name> of entity <destination>” node_templates: my_node: ...     interfaces:       Standard:         start:           implementation: start.sh assign: - value: { get_operation_output: [ SELF, Standard, start, pid ] } destination: SELF attribute_name: process_id

Define attributes as final See Simple YAML v1.1: section 3.5.10 (Attribute Definition) Goal – Protect system attributes or any attribute that should not be changed after it was assigned once Use case – Prevent from overriding system attributes Proposal – Add “final” keyname to attribute definition. Default false. tosca.nodes.Root: derived_from: tosca.entity.Root description: The TOSCA Node Type all other TOSCA base Node Types derive from attributes: tosca_id: type: string final: true tosca_name: state: ...

Enhance concat intrinsic function See Simple YAML v1.1: section 4.3.1 (Intrinsic functions, concat) Goal – Allow concatenation of values of different types with a custom delimiter Use case – Many use cases like generating names. Proposal – Add optional “delimiter” argument to “concat” and support all kind of data types. Alternative – Add a new “join” function and keep “concat”. outputs: example1: value: { concat: [["prefix", 1111, "suffix" ], "_" ] } # prefix_1111_suffix example2: value: { concat: [["prefix", 1111, "suffix" ]] } # prefix1111suffix Note: This enhancement is already existed in Heat template https://docs.openstack.org/developer/heat/template_guide/hot_spec.html#list-join Heat Orchestration Template - Intrinsic functions, list_join