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) Requirement s Container Capabilities Container Docker Requirement s 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

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) Requirements Capabilities artifacts: - image: mime_type: Docker?? repo: xxx, URI: xxx Artifacts Docker Image (Apache.TAR) requirements: - host: capability: tosca.capabilities.Container node: NULL relationship: tosca.relationships.HostedOn target_filter: capabilities: host: - type: docker capabilities: host: type: tosca.capabilities.Container valid_source_types: [NULL] Problem: How do we form a Relationship between Docker Requirement and Docker Capability? Do we need to? Compute Node has “Operating System” Capability Software Component uses “target_filter” to declare “os” properties No relationship However… 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 runtime_type: docker Container runtime_type: docker Container - type: docker Container - type: docker Policy (Kubernetes, Mesosphere) Placement/affinity Scaling affect cluster allocation Do not care about implementation

tosca.capabilities.Container: derived_from: tosca.capabilities.Roottosca.capabilities.Root properties: runtimes: type: tosca.datatypes.container.Runtime[] 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 name: type: string required false

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.