1. Software Component (Container + Containee) Software Component (Container + Containee) WebServer HostedOn Compute (Container) Compute (Container) Exploring Containment in TOSCA: Modeling WebServer with Compute Properties num_cpus mem_size disk_size Capabilities Requirements Container OpSys Scalable Container Artifacts Apache.TAR scripts requirements: - host: capability: tosca.capabilities.Container node: tosca.nodes.Compute relationship: tosca.relationships.HostedOn capabilities: host: type: tosca.capabilities.Container valid_source_types: [tosca.nodes.SoftwareComponent] capabilities: host: type: tosca.capabilities.Container valid_source_types: [ tosca.nodes.WebApplication ] Capabilities Container Effectively… Compute is a Container (Node Type) SoftwareComponent is both a Container and Containee (Node Type)

2. Docker Container Modeling Goals Goals (not requirements) Not proliferate Node Types for “Docker” 1.Consider modeling “Docker” as an (explicit) runtime Capability Type 2.Consider using a Property either within existing Container Capability Type within a new Containee Node Type Note: this is essentially how Azure PaaS does it 3.Consider using Artifact Type (i.e., Docker image) to imply Runtime Note: this is how CloudFoundry PaaS works (introspects app’s code) Allow model to allow Docker container so that it can be run on a PaaS (implicit container) an IaaS platform (explicit container) Note: this implies Compute Node and Container Node have interchangeable capabilities. If the Docker image has a WebServer (e.g., Apache) inside it, we want to reflect this in the TOSCA model Consider using existing WebServer Node Type Consider using a new WebServer Capability Type

3. Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Modeling Container-Containee like Compute-Software Component Expressing “Docker” as a Capability Type Containee (Docker Runtime Requirement) b Containee (Docker Runtime Requirement) b Capabilities Container Docker Requiremen ts Docker artifacts: - image: mime_type: Docker repo: xxx URI: xxx Software Component (Container + Containee) Software Component (Container + Containee) WebServer Compute (Container) Compute (Container) Capabilities Requirements Container OpSys Scalable Container Capabilities Container Artifacts Docker Image (Apache.TAR) requirements: - host: capability: tosca.capabilities.Container # node: NULL * relationship: tosca.relationships.HostedOn capabilities: host: type: tosca.capabilities.Container # valid_source_types: [NULL *] Requirement s Container IaaS Modeling -Compute is explicit or implicit PaaS Modeling Container is explicit or implicit Agnostic Cloud Foundry Azure directive: substitutable Container * “Effectively NULL”, not actually a NULL value. meaning, we do not need to bind to a Node Type

4. Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities Artifacts Docker Image (Apache.TAR) requirements: - host: # Primary Capability for relationship capability: tosca.capabilities.Container relationship: tosca.relationships.HostedOn target_filter: # 1-N secondary Capabilities… capabilities: - tosca.capabilities.runtime.Docker properties: - foo: bar capabilities: host: type: tosca.capabilities.Container valid_source_types: [NULL] docker: type: tosca.capabilities.runtime.Docker Container Final Proposal: Docker provided as a Capability in addition to “Container” Capability Type (but separate) This approach: First: formulates the primary requirement “host” to the Container Capability Type But also then: Provides a “target_filter” that lists 1..n Secondary Capability Types [Secondary] Capabilities expressed in “target_filter” do not have relationships. This approach ALSO allows us to: Treat some Capability Types more like a “decorators” Still pass in properties on any Secondary Capability Type Docker Rocket …

5. tosca.capabilities.Container: derived_from: tosca.capabilities.Roottosca.capabilities.Root properties: # re-located the following properties # from Compute node to make them portable # for any node having a Container capability. num_cpus: type: integer constraints: - greater_or_equal: 1 processing_power: # per cpu type: scalar-unit.speed required: false disk_size: type: scalar-unit.sizescalar-unit.size constraints: - greater_or_equal: 0 MB mem_size: type: scalar-unit.sizescalar-unit.size constraints: - greater_or_equal: 0 MB Note: We would still want to move Compute properties into Container capability (as in Variant 1) but without any new Runtime property (or DataType) Final Proposal: Docker provided as a Capability in addition to “Container” Capability Type

6. TOSCA will want to be able to show modeling against Docker “Compose” (links and components) with a basic lifecycle (fig now deprecated) announced 2015-02-25: http://blog.docker.com/2015/02/announcing-docker-compose/http://blog.docker.com/2015/02/announcing-docker-compose/ Show how we address their “roadmap” items already… “More than just development environments” Over time we will extend Compose's remit to cover test, staging and production environments. This is not a simple task, and will take many incremental improvements such as: Compose’s brute-force “delete and recreate everything” approach is great for dev and testing, but it not sufficient for production environments. You should be able to define a "desired" state that Compose will intelligently converge to. It should be possible to partially modify the config file for different environments (dev/test/staging/prod), passing in e.g. custom ports or volume mount paths. (#426)#426 Compose should recommend a technique for zero-downtime deploys.