instance model ad hoc group updates – february 2016 alessandro rossini derek palma sivan barzily
DESCRIPTION
Use Cases of interest Cluster management Run-time management Testing and validation (e.g. of TOSCA interpreters) Self-adaptive multi-cloud applications Big data applicationsTRANSCRIPT
Instance Model Ad Hoc GroupUpdates – February 2016
Alessandro Rossini Derek PalmaSivan Barzily
Logistics & Participant• Bi-weekly meetings take place on Wednesdays 6PM CET (noon
EST)• Participants:
– Danilo Ardagna (Politecnico di Milano)– Derek Palma (Vnomic)– Jacques Durand (Fujitsu America)– Paul Lipton (CA Technologies)– Antonio Brogi and Jacopo Soldani (SeaClouds)– Chris Lauwers (Ubicity)– Matthew Rutkowski (IBM)– Alessandro Rossini (SINTEF)– Sivan Barzily (GigaSpaces)
Use Cases of interest
• Cluster management• Run-time management• Testing and validation (e.g. of TOSCA
interpreters)• Self-adaptive multi-cloud applications• Big data applications
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– …
General Issues
1. Deriving the instance model from Templates, Types1. Is there complete information?
2. Accessing the instance model1. Orchestration time is already covered for the basic case
1. Information is can be passed to operations (declarative) but workflows require more2. Workflows may only see a part of the model, i.e. the nodes in defined states3. No navigation possible or definition of from where and in what runtime
2. Post orchestration, i.e. how do you look at the current state?1. From outside the topology via some (REST?) endpoint?2. Access properties, attributes, invoke operations? (like a workflow would do post initial deployment)
3. Are inputs, outputs, active policies, etc. also available?3. Instance model updates
1. What is visible during orchestration? E.g. lifecycle events, error status.2. How are topology and node status changes reflected over time? Change events?
Snapshots? …4. Serialization
1. It’s convenient to obtain a serialized representation of the entire model5. 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
Instance zTemplate ypropertiesAttributes
Dynamic info Normative? Env specific
Templates InstancesType Schema
Types
Met model of a TOSCA TypeE.g. Class, data type, references, attributes
Template yType xpropertiesattributes
Type xderived fromProperties name: typeattributes
Type w…
NodeType, CapabilityType, …
Parameterized “constructors”
Parameterized “constructors”