1. Instance Model Overview

2. Areas Design Considerations Workflow Interaction Resource Metadata
Model Structure

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 …
We need to define objectives AND non-objectives
Let’s come back to this after we survey the technique issues

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
No navigation possible or definition of from where and in what runtime
Post orchestration, i.e. how do you look at the current state?
From outside the topology via some (REST?) endpoint?
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? …
Serialization
It’s convenient to obtain a serialized representation of the entire model
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
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
Met model of a TOSCA Type
E.g. Class, data type, references, attributes
Parameterized “constructors”
NodeType, CapabilityType, …
Parameterized “constructors”

8. Workflow Inteaction

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

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

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

12. Resource Metadata

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

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

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

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

17. Model Structure

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

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

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

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

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

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

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

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

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

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