1. Instance Model Overview

2. Areas Design Considerations Model Structure
Workflow Interaction (State tracking/synchronization)
Resource Metadata

3. Design Considerations

4. Instance Model Objectives
Provide complete representation of the state of a TOSCA service template deployment
So it can be understood and appreciated by the owner
So a workflow can change it
So state or topology changes can be understood over time
So lifecycle operations can be manually applied to parts of it
Harmonize manual and autonomic operations …

5. General Issues Deriving the instance model from Templates, Types
Is there complete information?
Accessing the instance model
Orchestration time is already covered for the basic case
Information is can be passed to operations (declarative) but workflows require more
Workflows may only see a part of the model, i.e. the nodes in defined states
Navigation only possible across defined elements
Post orchestration, i.e. how do you look at the current state?
Dump instance model as YAML and/or access it programmatically?
Access properties, attributes, invoke operations? (like a workflow would do post initial deployment)
Are inputs, outputs, active policies, etc. also available?
Instance model updates
What is visible during orchestration? E.g. lifecycle events, error status.
How are topology and node status changes reflected over time? Change events? Snapshots? …
Correlation of modeled entities with external entities

6. Deriving the instance model
Service template instantiation
Templates represent the entities that can be created
But cardinality may vary
Orchestrator will compute/know the cardinality at some point
Processing the templates
Apply inputs
All aspects of the service template must be resolved (substitutable, sub-topologies, …)
Policies matched and intantiated
The context used from the runtime envronment should be reflected
Additional entities provided by environment might also appear
Load balancer, Backup, Directory service, Monitoring, DNS, NTP endpoints …
Location/placement of container entities and resources

7. 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
Meta-model of a TOSCA Type
E.g. Class, data type, references, attributes
NodeType, CapabilityType, …
Parameterized “constructors”
Actual instances

8. Work Areas Model Structure Workflow Interaction Resource Metadata
Encoding of information
Query/traversal
Workflow Interaction
Imperative interaction with the IM
State tracking/synchronization
Deterministic tracking/querying of state
Resource Metadata
Correlate TOSCA instances with actual resources

9. Model Structure

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

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

12. 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.
A[0]
B[0]
A[1]
B[1]
A[2]

13. Encoding Consider 2 approaches
DSL-like encoding
Instance model has structure similar to service template
Object tree encoding
Instance model is encoded more naturally as on object tree
Both are information preserving encodings
So it’s possible to translated between them
There was more interest in the Object tree encoding
More natural traversal
More natural representation
Extensibility in terms of objects (you can represent anything you want) versus DSL

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

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

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

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

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

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

20. Workflow Interaction

21. Workflow IM Information Requirements (basic)
Precondition
Determine if a workflow can be applied to a subset of nodes in a topology
Filter
Select the set of nodes on which the workflow will operate
Get lifecycle state
Know the state of a node to select the right sub-workflow/activities
Unknown state if node eventual enters a non-recoverable states
Set lifecycle state
Control state transitions as node operations are executed
Invoke operation
Pass parameters computed in the workflow
Deployment context access
Inputs
Instantiated policies
Service topology (Templates)
All respective meta info (Types)
Other?
Tenant
Location
Environment …

22. Workflow IM Query Requirements (advanced)
Qualify node by (node qualifier)
Type (Node Type Name)
Name (Node Template Name)
Ordinal (first, last, index, deterministic order for iterations/traversals)
Attribute values
node lifecycle state is an attribute
Defined or not (based on state)
Range (specific value is just a constrained range)
Any of (in)
Relation qualifier
Qualify by relation (relation qualifier)
Type
Name
Source nodes qualifier
Target nodes qualifier
Query syntax?
SQL like with graph semantics (in/out edges)

23. Pending issues Node lifecycle state Select template instances
Not defined in base types
getState (attribute)
setStat (state property?)
Select template instances
All instances created by a template
All templates create implicit homogenous sets of node instances
Groups in topology model can only refer to templates, i.e. they can’t target specific subsets of a sets
Where will IM queries be specified from
TOSCA workflow, policy
Can operations access instance model or just rely on inputs from TOSCA

24. Resource Metadata

25. Resource Metadata
Used to correlate TOSCA instances with actual resources
I.e. rationalize the instance model with the physical world
Used by other management software to correlate TOSCA topology with real world they already understand
Find specific things in the topology
Given TOSCA instance (by ID) find corresponding resource
Given a resource (by ID) find corresponding TOSCA instance
Concepts and semantics (assume invariant for now)
Resource entities (servers, networks, ports, …)
Identifying/Classification/grouping (IDs, refercences, tags, names, key/values)
Non-identifying/Facts (location, context, build, …)
Examples
Resource IDs (cloud APIs)
Tags (most resources in cloud APIs, cluster managers, etc.)
Annotations

26. Examples of metadata Kubernetes Cloud APIs, Virtualization, SDNs
Labels
Labels enable users to map their own organizational structures onto system objects in a loosely coupled fashion, without requiring clients to store these mappings.
"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"
Annotations
It is also useful to be able to attach arbitrary non-identifying metadata, for retrieval by API clients such as tools, libraries, etc. This information may be large, may be structured or unstructured, may include characters not permitted by labels, etc. Such information would not be used for object selection and therefore doesn’t belong in labels.
Cloud APIs, Virtualization, SDNs
Tags
Key value pairs

27. TOSCA instance to Resource mapping
1-1 mapping of instance to resource
Instance is backed by multiple resources N1 … N1 N2
TOSCA “logical” node instances
Resources “backing” logical instances R1 … RN R1 R2 … …
Metadata of multiple resource needs to be “grouped” at the instance
Metadata of single resource can be exposed in instance

28. Instance Model Representation
1 instance to 1 resource
When instance represents the resource
Use maps of maps in each node instance
First level denotes resource namespace (e.g. vsphere.VirtualMachine)
Next level denotes metdata kind (e.g. tags)
Next level contains values
1 instance to multiple resources
When there is not a simple 1-1 relationship between instance and resource and/or the resource is not really the same kind of thing the instance represents
Multiple resources (or even the environment) provide the metadata