Instance Model
Considerations
[email protected]
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
General Issues
1.
Deriving the instance model from Templates, Types
1.
2.
Is there complete information?
Accessing the instance model
1.
Orchestration time is already covered for the basic case
1.
2.
3.
2.
Post orchestration, i.e. how do you look at the current state?
1.
2.
3.
3.
Are inputs, outputs, active policies, etc. also available?
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
1.
5.
From outside the topology via some (REST?) endpoint?
Access properties, attributes, invoke operations? (like a workflow would do post initial deployment)
Instance model updates
1.
2.
4.
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
It’s convenient to obtain a serialized representation of the entire model
Correlation of modeled entities with external entities
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
Information Model
Type Schema
Templates
Types
Instances
Type w
…
Type x
derived from
Properties
name: type
attributes
Met model of a
TOSCA Type
E.g. Class, data
type, references,
attributes
NodeType,
CapabilityType, …
Template y
Type x
properties
attributes
Instance z
Template y
properties
Attributes
Dynamic info
Normative?
Env specific
Parameterized
“constructors”
Parameterized
“constructors”