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)

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

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) Containee (Docker Runtime Requirement) 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 Problem: How do we form a Relationship between Docker Requirement and Docker Capability? Do we need to? directive: substitutable Container

Hosted On Software Component Container (Docker Runtime Capability) Container (Docker Runtime Capability) Variant 1: Docker provided as a Property within “Container” Capability Type Containee (Docker Runtime Requirement) Containee (Docker Runtime Requirement) Requirements Capabilities Artifacts Docker Image (Apache.TAR) requirements: - host: capability: tosca.capabilities.Container relationship: tosca.relationships.HostedOn target_filter: capabilities: - host : properties: - runtimes: { [ docker ] } capabilities: host: type: tosca.capabilities.Container valid_source_types: [NULL] Problem: How do we communicate the Docker Requirement without using a 2 nd relationship? This approach has a precedent in TOSCA already: Compute Node has “Operating System” Capability Software Component uses “target_filter” to declare “os” properties it wants (a pseudo-requirement) No relationship This is possible since… OperatingSystem Capability has “type-like” Properties inside it: (now optional) Architecture (now optional) Type (now optional) Distribution (optional) Version If we follow this paradigm we would add “type-like” Properties to Container Capability: (optional) Runtime Type: “Docker” (optional) Version Container

tosca.capabilities.Container: derived_from: tosca.capabilities.Roottosca.capabilities.Root properties: runtimes: type: tosca.datatypes.container.Runtime[] # 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 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 Conceptually: A logical Container MAY support 1..n runtime environments These runtimes MAY be versioned Define new Datatype to reflect the type/version pairing Containers Virtualize runtime resources CPU/VPU, memory, local storage Compute is a Container, but these properties are now in the Node Recommend: Move properties to Container capability We SHOULD denote Compute node as “selectable” for most (every?) use case tosca.datatypes.container.Runtime: properties: # runtime type, e.g. Docker, Rocket, Java, etc. type: type: string # runtime version, JRE7, version: type: version required: false default: 0 Variant 1: Docker provided as a Property within “Container” Capability Type

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: capability: tosca.capabilities.Container relationship: tosca.relationships.HostedOn target_filter: 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 Variant 2: 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

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 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) Variant 2: Docker provided as a Capability in addition to “Container” Capability Type

TOSCA will want to be able to show modeling against Docker “Compose” (links and components) with a basic lifecycle (fig now deprecated) announced : 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.