Software Component(Container + Containee)Software Component(Container + Containee)

WebServerWebServer

HostedOn

Compute(Container)Compute

(Container)

Exploring Containment in TOSCA: Modeling WebServer with Compute

Properties• num_cpus• mem_size• disk_size

Capabilities

Requirements

ContainerContainer

OpSysOpSys

ScalableScalable

ContainerContainer

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

ContainerContainer

• 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 Type2. Consider using a Property either

• within existing Container Capability Type <or>• within a new Containee Node Type

• Note: this is essentially how Azure PaaS does it3. 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) <or>• an IaaS platform (explicit container)• Note: this implies Compute Node and Container Node have interchangeablecapabilities.

• 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

Hosted On

Software Component

Container(Docker Runtime

Capability)

Container(Docker Runtime

Capability)

Modeling Container-Containee like Compute-Software ComponentExpressing “Docker” as a Capability Type

Containee(Docker Runtime

Requirement)

Containee(Docker Runtime

Requirement)

Requirements

ContainerContainer

Capabilities

ContainerContainer

DockerDocker

Requirements

DockerDockerartifacts: - image: mime_type: Docker repo: xxx URI: xxx

Software Component(Container + Containee)

Software Component(Container + Containee)

WebServerWebServer

Compute(Container)Compute

(Container)

Capabilities

Requirements

ContainerContainer

OpSysOpSys

ScalableScalable

ContainerContainer

Capabilities

ContainerContainer

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]

Requirements

ContainerContainer

IaaS Modeling- Compute is explicit or implicit

PaaSModeling• 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 ComponentExpressing “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 relationshipHowever… • 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

Containerruntime_type: docker

Containerruntime_type: docker

Container- type: dockerContainer- type: docker

Policy (Kubernetes, Mesosphere)• Placement/affinity• Scaling• affect cluster allocation• Do not care about implementation

tosca.capabilities.Container: derived_from: tosca.capabilities.Root properties: runtimes: type: tosca.datatypes.container.Runtime[] num_cpus: type: integer constraints: - greater_or_equal: 1 disk_size: type: scalar-unit.size constraints: - greater_or_equal: 0 MB mem_size: type: scalar-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: version: type: version required: false default: 0 name: type: string required false type: type: string