1. Instance Model Structure

2. 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

3. 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”

4. Service Template Under-Specification Items Impacting Instance Model

5. 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]

6. 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

7. 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.

8. 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

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

10. 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

11. 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
URI
Fragment

12. 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

13. 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": " } 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.