Container Hierarchies and Related Issues

Slides:



Advertisements
Similar presentations
NAGIOS AND CACTI NETWORK MANAGEMENT AND MONITORING SYSTEMS.
Advertisements

Why Do We Need a (Plan) Portability API? Gerd Breiter Frank Leymann Thomas Spatzier.
Mapping Service Templates to Concrete Network Semantics Some Ideas.
Proposal by CA Technologies, IBM, SAP, Vnomic
Docker Container Modeling Goals Goals (not requirements) Not proliferate Node Types for “Docker” 1.Consider modeling “Docker” as an (explicit) runtime.
PlanetLab Operating System support* *a work in progress.
Docker Container Modeling Goals Goals (not requirements) Not proliferate Node Types for “Docker” 1.Consider modeling “Docker” as an (explicit) runtime.
Software Component (Container + Containee) Software Component (Container + Containee) WebServer HostedOn Compute (Container) Compute (Container) Exploring.
Software Component (Container + Containee) Software Component (Container + Containee) WebServer HostedOn Compute (Container) Compute (Container) Exploring.
Evaluate container lifecycle support in TOSCA TOSCA – 174 Adhoc TC.
Cloud Computing Systems Lin Gu Hong Kong University of Science and Technology Sept. 21, 2011 Windows Azure—Overview.
CSC 8310 Programming Languages Meeting 2 September 2/3, 2014.
TOSCA Workloads with OpenStack Heat-Translator
Software Component (Container + Containee) Software Component (Container + Containee) WebServer HostedOn Compute (Container) Compute (Container) Exploring.
Additional SugarCRM details for complete, functional, and portable deployment.
Database System Concepts and Architecture Lecture # 3 22 June 2012 National University of Computer and Emerging Sciences.
TOSCA Monitoring Working Group Status Roger Dev August 10, 2015.
CS 346 – Chapter 8 Main memory –Addressing –Swapping –Allocation and fragmentation –Paging –Segmentation Commitment –Please finish chapter 8.
Proposal by CA Technologies, IBM, SAP, Vnomic
Network Connectivity Use Case Modeling and YAML Syntax
NETWORK CONNECTIVITY USE CASES AT CARRIER / SERVICE PROVIDERS CloudBand June 2014.
Lesson 3 CDT301 – Compiler Theory, Spring 2011 Teacher: Linus Källberg.
Software Component (Container + Containee) Software Component (Container + Containee) WebServer HostedOn Compute (Container) Compute (Container) Exploring.
Knowledge Modeling, use of information sources in the study of domains and inter-domain relationships - A Learning Paradigm by Sanjeev Thacker.
Kind: “Pod” (i.e. Type) kind: “Pod” (i.e. Type) Kubernetes Analysis: 2 types of containers “Dumb” (no HA, no Autoscale) = Pod Template kind: “ReplicationController”
TOSCA Name Used by (Roles)Modeling conceptDistinguishing traitsNotes Node TypeType Developers Experts that fully understand, package an constrain, properties,
SugarCRM Use Case: Plans 1. Reminder When a service template is deployed, its implementation artifacts are deployed – From that time on, the operations.
 All calls to method toString and earnings are resolved at execution time, based on the type of the object to which currentEmployee refers.  Known as.
School of Computer Science & Information Technology G6DICP - Lecture 4 Variables, data types & decision making.
M180: Data Structures & Algorithms in Java Trees & Binary Trees Arab Open University 1.
© Drexel University Software Engineering Research Group (SERG) 1 The OASIS SOA Reference Model Brian Mitchell.
Normative Types & connectsTo The RelationshipType base type of “connectsTo” in the current draft on Normative Types in Tosca seems to be incomplete. In.
Kind: “Pod” (i.e. Type) kind: “Pod” (i.e. Type) Kubernetes Analysis: 2 types of containers “Dumb” (no HA, no Autoscale) = Pod Template kind: “ReplicationController”
“Custom” Checks/Constraints/Actions A proposal for the OASIS SDD TC Rich Aquino, Macrovision Julia McCarthy, IBM March 1, 2007.
Evaluate container lifecycle support in TOSCA TOSCA – 174 Adhoc TC.
NETWORK CONNECTIVITY USE CASES AT CARRIER / SERVICE PROVIDERS CloudBand June 2014.
Evaluate container lifecycle support in TOSCA TOSCA – 174 Adhoc TC.
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. TOSCA 115 Capability Interfaces.
Objective Propose a simple and concise set of “Core” Entities and Relations for TOSCA useful for any application deployment in a cloud Enable users to.
TOSCA v1.0 Figures. Definition of building blocks for services … along with the implementation artifacts for manageability operations … and the definition.
Anupam Joshi University of Maryland, Baltimore County Joint work with Tim Finin and several students Computational/Declarative Policies.
INSTANCE MODEL AD HOC GROUP UPDATES Alessandro Rossini Sivan Barzily March 2016.
Instance Model Considerations Instance Model Objectives Provide complete representation of the state of a TOSCA service template deployment.
Evaluate container lifecycle support in TOSCA TOSCA – 174 Adhoc TC.
1 Cluster – defn. TBD Derek: Homogenous set of nodes; in TOSCA that is a single node template. -Matt said this can also be viewed as a stack -- Derek can.
TOSCA workflows. Default workflow is declarative (generated from nodes and relationships) install at the beginning of install workflow all instances are.
Update for tosca-nfv-profile
SDN-O LCM for Mercury Release Key Points and Overview
Mapping between NFV model and TOSCA
User-centred system design process
Kubernetes Analysis: 2 types of containers
Cluster – defn. TBD Derek:
VNFD and NSD modeling: Rel2 Thinh Nguyenphu, Nokia thinh
Workflow-Instance Model Interaction
Deployment Flavour as VNF Capability: Alt1_r3
Drupal VM and Docker4Drupal For Drupal Development Platform
TOSCA Matching Or how the orchestrator provides implementation for abstract nodes or dangling requirements.
Drupal VM and Docker4Drupal as Consistent Drupal Development Platform
DF design as a node type (output by Chris and shitao)
DF design as a node type (output by Chris and shitao)
TOSCA Workflow Proposal
Remain issues
Instance Model Structure
TOSCA workflows.
Models and Infrastructure for Pervasive Computing
Deployment Flavour as VNF Capability: Alt1_r2
Lifecycle Management Automation through TOSCA
CS2013 Lecture 7 John Hurley Cal State LA.
TOSCA v1.3 Enhancements February 21, 2019.
WP3: BPaaS Research Execution Environment
Presentation transcript:

Container Hierarchies and Related Issues

Hierarchical Containers Occur in Nature Docker Platform Docker OS Platform Docker OS VM Docker OS VM ServerPlatform Containers provide resources to containers. They either provision new resources from the environment or partition their own resources. Providing resources is a capability of containers. In practice we’d like ignore containers if we don’t care to control them. If we need more control we might model them declaratively (capability types) or structurally (nodes types)

Container Issues in TOSCA The Docker use case forces us to consider container hierarchies Your platform could host the Docker container directly OR Expose a container management framework OR Actually deploy the container management framework in the topology... This is nothing new, consider Java web apps and JVMs. Other languages/frameworks have similar structures TOSCA currently specifies resources only at the Compute node level This requires tweaking the Compute resource configuration each time a nodes are added/removed from it Does not allow nodes to specify their resource requirements Makes monitoring hard if you don’t know what resources a node consumes and how it obtains those resources from a container

How can we resolve these issues? The TOSCA DSL can describe hierarchical container semantics In a sense, just need to add the container types we want to manage And ensure any depth of hierarchy can be supported Allow TOSCA implementations to decide which container they support natively (i.e. without the user providing lifecycle operations for them) Concisely express resource requirements via explicit resource capabilities Move resource properties into a capability type (well it could still be a node type but we don’t want to pollute with non-resource related properties) Support capability delegation semantics Allow containee nodes to delegate capability fulfillment to its container. E.g. propagate memory usage down to the root container which actually can fulfill it.

New capability, node and relationship for resource aware containment hierarchies tosca.capabilities.ComputeResource derived_from: tosca.capabilities.Root properties: num_cpus: type: integer constraints: - greater_or_equal: 1 mem_size: type: scalar-unit.size constraints: - greater_or_equal: 0 MB tosca.nodes.ResourceContainer: derived_from: tosca.nodes.SoftwareComponent capabilities: host: type: tosca.capabilities.ComputeResource valid_types: [ tosca.nodes.ResourceCompute ] tosca.relationships.ResourceHostedOn: derived_from: tosca.relationships.HostedOn # or not valid_targets: [ tosca.capabilities.ResourceContainer ]

Types for Docker tosca.nodes.DockerApp derived_from: tosca.nodes.Root propreties: requirements: - host: node: tosca.nodes.DockerContainer relationship: tosca.relationships.ResourceHostedOn webserver: type: tosca.nodes.DockerContainer properties: image: ubuntu/apache requirements: - host: ? # don’t specific if you don’t care to control containers explicitly interfaces: tosca.interfaces.node.Lifecycle: configure: input: links: mysql_dbms tosca.nodes.DockerContainer: derived_from: tosca.nodes.ResourceContainer properties: image: type: string decription: / # could be a real URI too run_privileged: type: boolean description: container is given access to all devices capabilities: host: type: tosca.capabilities.ComputeResource valid_types: [ tosca.nodes.DockerApp ]

Remaining Container Hierarchy tosca.nodes.OSApp derived_from: tosca.nodes.Root requirements: - host: node: tosca.nodes.OperatingSystem relationship: tosca.relationships.ResourceHostedOn tosca.nodes.OperatingSystem: derived_from: tosca.nodes.ResourceContainer capabilities: host: type: tosca.capabilities.ComputeResource valid_types: [ tosca.nodes.OSApp ] tosca.nodes.VirtualMachine: derived_from: tosca.nodes.ResourceContainer capabilities: host: type: tosca.capabilities.ComputeResource valid_types: [ tosca.nodes.OperatingSystem ] tosca.nodes.Server derived_from: tosca.nodes.ResourceContainer capabilities: host: type: tosca.capabilities.ComputeResource valid_types: [ tosca.nodes.OperatingSystem ] tosca.nodes.ResourceCompute: derived_from: tosca.nodes.Compute capabilities: host: type: tosca.capabilities.ComputeResource valid_types: [tosca.nodes.ResourceContainer ]