Instance Model Structure dpalma@vnomic.com

Serialization to YAML Allows us to look at a snapshot of the instance model without having to define query/navigation techniques … but need to maintain a clear concept of the information to be represented Approach: Encode input values provided by user as input_instances Encode policies applied as policy_instances linking to affected templates and instances Encode requirement resolution as needed for automated matching for fulfillment Generate node_instances for final topology Encode output with final values

Information Model Type Schema Types Templates Instances Type w … Template y Type x properties attributes Instance z Template y properties Attributes Dynamic info Normative? Env specific Type x derived from Properties name: type attributes Met model of a TOSCA Type E.g. Class, data type, references, attributes Parameterized “constructors” NodeType, CapabilityType, … Parameterized “constructors”

Service Template Under-Specification Items Impacting Instance Model

Relations between Node Instances Node Template A Node Template B M N Node instances have m x n cardinality by default but we’ll need to support other kind of configurations. Service template must specify this mapping, for example: 2:1 -> every 2 source maps to 1 target *:* -> every source maps to every target *:!2 -> every source maps to a unique target pair … A[0] B[0] A[1] B[1] A[2]

Cluster node lifecycle and attribute synchronization Generalized declarative orchestration Imperative already is planning these features Wait for a set of node instances to reach a particular lifecycle state All cluster node instances running All Zookeeper instances ready before starting nodes that need ZK service Multiple sets of instances needing ZK service At least N instances in some state Wait for a set of node instances to reach specific attribute states Same idea applied to attribute values (states) Generalize to constraints as logical expressions This is just specification of specific lifecycle and attribute states for sets of nodes

Instance Model Example Unstructured approach where node instances are in same list and not grouped by template. Each node instance indicates its template but only way to group is to query for matching template name.

Instance Model Specific Serialization Issues Users may want to include information defined from other standards/meta models Implementations may want to include additional information in TOSCA instances E.g. resource mapping information Structural information indicating relationships among other entities Implementations may want to include information not part of TOSCA instances TOSCA does not have all the features to support object trees Referencing entities in other subtrees (can only reference specific instances by name, no collections) Generalized referencing that work in document, cross document with relative and absolute URIs Collections Referencing entities in ordered collections Referencing entities by key

Reference semantics A D Containment Reference B C E C Cross Reference

Extensions for General Information Representation Enhance data types: Explicitly denote containment and cross reference Reference other documents and namespaces using URIs and fragments Fragments with index New section object_instances to hold generic data objects not TOSCA instances Support indexing into a list

Adding referencing to YAML JSON had to solve similar problem (solved originally in XML) JSON Schema Motivates referencing JSON Pointer JSON Reference Interesting: XMI JSONPath (no formal spec???) JSON-LD http://abc.com/schemas/abc_data_types#/data_types/tosca.datatypes.AbcType URI Fragment

JSON Pointer URI Fragment Identifier Representation A JSON Pointer can be represented in a URI fragment identifier by encoding it into octets using UTF-8 [RFC3629], while percent-encoding those characters not allowed by the fragment rule in [RFC3986]. Note that a given media type needs to specify JSON Pointer as its fragment identifier syntax explicitly (usually, in its registration [RFC6838]). That is, just because a document is JSON does not imply that JSON Pointer can be used as its fragment identifier syntax. In particular, the fragment identifier syntax for application/json is not JSON Pointer. Bryan, et al. Standards Track [Page 5] RFC 6901 JSON Pointer April 2013 Given the same example document as above, the following URI fragment identifiers evaluate to the accompanying values: # // the whole document #/foo ["bar", "baz"] #/foo/0 "bar" #/ 0 #/a~1b 1 #/c%25d 2 #/e%5Ef 3 #/g%7Ch 4 #/i%5Cj 5 #/k%22l 6 #/%20 7 #/m~0n 8 { "foo": ["bar", "baz"], "": 0, "a/b": 1, "c%d": 2, "e^f": 3, "g|h": 4, "i\\j": 5, "k\"l": 6, " ": 7, "m~n": 8 } Sample fragment identifiers Sample Document

JSON Reference (for inspiration) A JSON Reference is a JSON object, which contains a member named "$ref", which has a JSON string value. Example: { "$ref": "http://example.com/example.json#/foo/bar" } If a JSON value does not have these characteristics, then it SHOULD NOT be interpreted as a JSON Reference. The "$ref" string value contains a URI [RFC3986], which identifies the location of the JSON value being referenced. It is an error condition if the string value does not conform to URI syntax rules. Any members other than "$ref" in a JSON Reference object SHALL be ignored.