1. INSTANCE MODEL AD HOC GROUP UPDATES Alessandro Rossini Sivan Barzily March 2016

2. Logistics Bi-weekly meetings take place on Wednesdays 6pm CET (noon EST) Suggestion – change to a weekly meeting (TBD)

3. Current Status Defined: Objectives Initial use case (cluster) Consumption Design consideration Next steps: Agree on design principals Define the actual model Deriving the instance model (how to populate the model with real data)

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 So relationship operations can be defined on specific instances Enable testing and validation of TOSCA interpreters and orchestrators

5. Instance Model Consumption Consumers: The TOSCA orchestrator Workflows that the orchestrator delegates to Clients accessing the instance model of a live deployment Accessibility: Before, after and during orchestration Workflows may only see a part of the model, i.e. the nodes in defined states Representation: It’s convenient to obtain a serialized representation of the entire model Necessary to also be able to traverse the instances graph

6. Design Considerations State based orchestration state retrieval and consideration is essential Orchestrator states vs real world states –orchestrators depend on operations reports (as opposed to monitoring tools) To track state changes it might be more useful to have a track log, instead of querying the actual state every As nodes are transitioned only a subset of their states are valid 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? …

7. Deriving the instance model - considerations 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

8. Questions? Suggestions?