Approach Use reuse exiting TOSCA normative node capability

Approach: • Use reuse exiting TOSCA normative node, capability and relationship types where possible • Model Kubernetes types (for now), then model similar container managers like Swarm, etc. and look for common base types, properties that can be abstracted. Kubernetes Analysis: 2 types of containers “Dumb” (no HA, no Autoscale) = Pod Template “Smart” (HA, Scaling) = Replication. Controller Template kind: “Pod” (i. e. Type) kind: “Replication. Controller” (i. e. Type) id: redis-master labels: kind: Pod name: redis api. Version: v 1 beta 1 role: master desired. State: redis-sentinel: "true" manifest: version: v 1 beta 1 id: redis-master containers: - name: master image: kubernetes/redis: v 1 cpu: 1000 ports: - container. Port: 6379 volume. Mounts: - name: data mount. Path: /redis-master-data env: - key: MASTER value: "true" - name: sentinel image: kubernetes/redis: v 1 ports: - container. Port: 26379 env: - key: SENTINEL value: "true" volumes: - name: data source: empty. Dir: {} id: redis kind: Replication. Controller api. Version: v 1 beta 1 desired. State: replicas: 1 replica. Selector: name: redis pod. Template: desired. State: manifest: version: v 1 beta 1 id: redis containers: - name: redis image: kubernetes/redis: v 1 cpu: 1000 ports: - container. Port: 6379 volume. Mounts: - name: data mount. Path: /redis-master-data volumes: - name: data source: empty. Dir: {} labels: name: redis

• Kubernetes Analysis: Pod Modeling: TOSCA Type mapping A Pod is an aggregate of Docker Container Requirements of 1. . N homogenous Container (topologies) “Redis-master” Template of Kubernetes “Pod” Type: kind: “Pod” (a Template of type “Pod”) id: redis-master kind: Pod labels: api. Version: v 1 beta 1 name: redis desired. State: role: master manifest: redis-sentinel: "true" version: v 1 beta 1 (non-numeric) id: redis-master containers: ------------------------------------------------- name: master (TOSCA template name) image: kubernetes/redis: v 1 (TOSCA Container. App; create artifact of type image. Docker) cpu: 1000 (TOSCA Container capability; num_cpus, cpu_frequency) ports: (TOSCA End. Point capability) - container. Port: 6379 (TOSCA Endpoint; port, ports) volume. Mounts: (TOSCA Attachment capability) - name: data mount. Path: /redis-master-data (TOSCA Attaches. To Rel. ; location) env: - key: MASTER value: "true” # passed as Envirronment vars to instance ------------------------------------------------ name: sentinel image: kubernetes/redis: v 1 ports: - container. Port: 26379 env: - key: SENTINEL value: "true” # passed as Env. var. ------------------------------------------------volumes: - name: data source: empty. Dir: {} TOSCA Types for Kubernetes: Kubernetes. Pod tosca. groups. Placement derived_from: tosca. groups. Placement version: metadata: description: properties: TBD attributes: TBD # Allow get_property() against targets: [ tosca. nodes. Container. App. Kubernetes ] Kubernetes. Container tosca. nodes. Container. App derived_from: tosca. nodes. Container. App metadata: version: description: properties: environment: requirements: - host: # hosted on kubelets type: Container. Runtime. Kubernetes - ports: capability: End. Point properties: ports, etc. - volumes: capability: Attachment relationship: Attaches. To properties: location, device occurrences: [0, UNBOUNDED]

Kubernetes Analysis: Pod Modeling: TOSCA Template Mapping: Simple “Group Approach”: • Using the Types defined on the previous slide the TOSCA Topology Template looks like this for “redis-master” TOSCA Topology for Kubernetes “: “Redis-master” Template of Kubernetes “Pod” Type: redis-master-pod Kubernetes. Pod kind: “Pod” (a Template of type “Pod”) id: redis-master kind: Pod labels: api. Version: v 1 beta 1 name: redis desired. State: role: master manifest: redis-sentinel: "true" version: v 1 beta 1 (non-numeric) id: redis-master containers: ------------------------------------------------- name: master image: kubernetes/redis: v 1 cpu: 1000 ports: - container. Port: 6379 volume. Mounts: - name: data mount. Path: /redis-master-data env: - key: MASTER value: "true” # passed as Envirronment vars to instance ------------------------------------------------ name: sentinel image: kubernetes/redis: v 1 ports: - container. Port: 26379 env: - key: SENTINEL value: "true” # passed as Env. var. ------------------------------------------------volumes: - name: data source: empty. Dir: {} type: tosca. groups. Placement implied “Invites. To” Relationship version: 1. 0 metadata : implied “Invites. To” Relationship name: redis role: master redis-sentinel: true targets: [ master-container , sentinel-container ] master-container Kubernetes. Container derived_from: Kubernetes. Container metadata: version: description: artifacts: kubernetes/redis: v 1 properties: requirements: - host: properties: num_cpus: 1000 ? - port: capability : End. Point properties: port: 6379 - volume: capability: Attachment relationship: Attaches. To properties: location, device occurrences: [0, UNBOUNDED] interfaces: inputs: MASTER: true sentinel-container Kubernetes. Container derived_from: Kubernetes. Container. . Choice: or use Docker. Runtime type to allow use of template on Swarm, etc. ? Issue: location property lost as there is no “Attaches. To” relationship in the topology. Create new Capability Type? Issue: Are there more than 1 volumes / mount points allowed?

Membership (Member. Of) direction is wrong for management (group): TOSCA Groups redis-master-pod implied “Member. Of” Relationship Kubernetes. Pod type: tosca. groups. Placement sources: [ master-container , implied “Member. Of” Relationship sentinel-container ] master-container sentinel-container Kubernetes. Container derived_from: Kubernetes. Container. .

However: We do not want to “buy into” Docker file as a Capability Type: Old Style: Docker capability type that mirrors a Dockerfile: tosca. capabilities. Container. Docker: derived_from: tosca. capabilities. Container properties: version: type: list required: false entry_schema: version publish_all: type: boolean default: false required: false publish_ports: type: list entry_schema: Port. Spec required: false expose_ports: type: list entry_schema: Port. Spec required: false volumes: type: list entry_schema: string required: false Instead we want to use Endpoints (for ports) and Attachments (for volumes) This allows Docker, Rocket and containers to be modeled with other TOSCA nodes (i. e. , via Connects. To) and leverage underlying Compute attached Block. Storage TBD: Need to show this

BETTER: We do not need to define Kubernetes specific Types (reuse Docker types) : Kubernetes Pod reuses “Docker” Container. App type which can now reference other Container. App types like Rocket (Rkt) tosca. groups. Placement tosca. groups. Root derived_from: tosca. groups. Placement version: metadata: description: properties: TBD attributes: TBD # Allow get_property() against targets: [ Container. App. Docker, Container. App. Rocket, . . . ] Policies: Security, Scaling, Update, etc. • • “Applies. To” group (members) • i. e. , targets • Not using “Binds. To” as that implies it is coupled to an implementation Container. App. Docker tosca. nodes. Container. App derived_from: tosca. nodes. Container. App metadata: version: description: capabilities: Container. App: attribute: response_time: properties: environment: requirements: - host: • There is no need for a “Kubernetes” Runtime type, just use the real Container’s built-in runtime requirement • (don’t care to model or reference Kubelets) • Homogenous Pods/Containers for Kubernetes is still an issue, but • this is a current Kubernetes limitation • (heterogonous is possible in future) Container. App. Rocket Container. APP capability: Container. Docker type: Container. Runtime. Kubernetes - ports: capability: End. Point properties: ports, etc. - volumes: capability: Attachment relationship: Attaches. To properties: location, device occurrences: [0, UNBOUNDED] derived_from: Kubernetes. Container. .

TOSCA Policy – Entities that compose Policy (Event, Condition, Action) model Event Type (new): Policy Definition : derived_from: version: description: : type: description: properties: # allowed targets for policy association targets: [ ] * : event: # TODO: Allow a TOSCA node filter here # required node (resource) to monitor cap node: < node_type? # Used to reference another node related to # the node above via a relationship requirement: # optional capability within node to monitor capability: # required clause that compares an attribute # with the identified node or capability # for some condition: action: # a) Define new TOSCA normative strategies # per-policy type and use here OR # b) allow domain-specific names : # TBD: Do we care about validation of types? # If so, we should use a TOSCA Lifecycle type inputs: : . . . : Event name of a normative TOSCA Event Type Condition described as a constraint of an attribute of the node (or capability) identified) by the filter. Action Describes either: a)a well-known strategy b)an implementation artifact (e. g. , scripts, service) to invoke with optional property definitions as inputs (to either choice)

Possible TOSCA Metamodel and Normative Type additions Node. Type, Rel. Types : metadata: description: > allow tags / labels for search of instance model type: map of string derived_from: version: description: properties: attributes: requirements: - capabilities: interfaces: artifacts: tosca. capabilities. Container: derived_from: tosca. capabilities. Root properties: num_cpus: type: integer required: false constraints: - greater_or_equal: 1 cpu_frequency: type: scalar-unit. frequency required: false disk_size: type: scalar-unit. size required: false mem_size: type: scalar-unit. size required: false attributes: utilization: description: referenced by scaling policies type: float (percent) | integer (percent) | scalar-percent ? required: no ? constraints: - in_range: [ 0, 100 ]

TOSCA Policy Mapping – Example Senlin “scaling_out_policy_ceilometer. yaml” using the Kubernetes “redis” example from earlier slides (and its pod, container): TOSCA Policy Definition Target is a Kubernetes Pod of the tosca. groups. placement type my_scaling_policy: TOSCA normative event type: tosca. policies. scaling (name) that would map to # for now any TOSCA node Symbolic name domain-specific names (e. g. , targets: [redis-master-pod ] for the trigger Open. Stack Ceilometer) triggers: (could be used to resize_compute: reference an externalized event: tosca. events. resource. utilization version; however, this Find the attribute via the topology: node_filter: would violate a a) Navigate to node (directly or via the node: master-container Policy’s integrity as a requirement name) and optionally the requirement: host capability: Container Capability name “Security document” condition: utilization > 80% b) The condition to map & register with the action: target monitoring service (e. g. , Ceilometer) # reuse part of a lifecycle RESIZE_BEST_EFFORT: # TODO: number: 1. . . Look to use the TOSCA node_template grammar here i. e. , The “node”, “req”, “cap” and “condition” keys would expressed as a node_filter List your input parms. here Note: we combined the Senlin “Action” of SENLIN: ACTION: RESIZE with the strategy: BEST_EFFORT to have one name TODO: Need a % data type for TOSCA

Backup

TOSCA Policy Type – Based upon Event, Condition, Action model Policy Type Event(s) based upon resource in TOSCA topology or a Capability of that resource. Policy Definition : derived_from: version: description: properties: targets: [ ] events: # requirement-like? : node: # Compute -> Nova capability: # Container attribute: # cpu_utilization -> cpu. . . strategies: # set of strategy names and # strategy-specific properties : type: description: properties: targets: [ ] * see below events: : node: capability: triggers: # expression of the Condition # e. g. , utilization_percent > 80% filter: condition: action: # e. g. , utilization_level: RED filter: action: # TODO: Perhaps make this a policy lifecycle def. actions: - : value: properties: # TODO: See if we can avoid imperative scripts - : type: operation (senlin = custom action) value: Old proposal # TODO: Perhaps define policy lifecycle Condition(s) described as a constraint of an attribute of aresource (or capability of the resource) Action(s) 1) A strategy that matches the policy type 2) An scripts 3) Notifications * node, relationship templates (or groups)

Software Component 1: SW Component with VM image deployment artifact master Container. App. Kubernetes redis_master Properties • TBD Attributes • TBD Kubernetes. Pod Properties • TBD Attributes • TBD Artifacts: • kubernetes/redis: v 1 • type: image. Docker Requirements Container. Runtime. Docker Properties • TBD Lifecycle. Standard Hosted. On create … Capabilities Container. Runtime. Docker sentinel Hosted. On Container. App. Kubernetes Properties • TBD Attributes • TBD Requirements Artifacts: • kubernetes/redis: v 1 • type: image. Docker

‘wordpress’ Docker Image Docker Hub (Repository) wordpress_container ‘mysql’ Docker Image mysql_container Container. Application. Docker artifacts: - my_image: type: Image. Docker URI: wordpress repository: docker_hub - my_image: type: Image. Docker URI: mysql repository: docker_hub Requirements Container Runtime. Docker. Links. To Capabilities Docker. Link