1. 1 Cluster – defn. TBD Derek: Homogenous set of nodes; in TOSCA that is a single node template. -Matt said this can also be viewed as a stack -- Derek can be represented as a single “container” template (which Compute is a node template for a “stack” container. -Can be treated symmetrically - tier lifecycles are independent of each other - therefore no dependencies on each other (from a mgmt.. perspective) -Matt: perhaps use ELK for starters, to work thru? -Matt: Cluster conveys “mgmt” to the provider, whatever is “inside” (i.e., members) can be managed via the Cluster (node) using the capabilities (e.g., LoadBalancer, Router, etc.)

2. 2 Single Compute/Container Eg. single Docker container, scaling, load balancing (, placement)

3. 3 my_docker_lambda_fx tosca.nodes.Container.App.Docker properties:... capabilities: - Endpoint 1..N HTTP RESTful endpoint, single entry Container Manager MUST infer capabilities for: LoadBalancer: Needed to distribute “load” as measured by platform provider Router: needs to be created by provider to route between instances Scaling Policy LoadBalancing Policy Could be autonomous containers? Any Cloud platform MUST have some defact “Container manager” (cant have more than 1 of the container without some function to manage resources)

4. 4 landa_fx_cluster Cluster type: tosca.groups.Root members: [ my_docker_lambda_fx ] capabilities: LoadBalancing: Router:... my_docker_lambda_fx tosca.nodes.Container.App.Docker properties:... capabilities: - Endpoint 1..N HTTP RESTful endpoint, single entry Container Manager has explicit Capabilities declared: LoadBalancer: Needed to distribute “load” as measured by platform provider Router: needs to be created by provider to route between instances Scaling Policy LoadBalancing Policy Scaling Policy LoadBalancing Policy X X

5. 5 landa_fx_cluster Cluster type: tosca.groups.Root members: [ my_docker_lambda_fx1, my_docker_lambda_fx2 ] capabilities: LoadBalancing: Router:... my_docker_lambda_fx1 tosca.nodes.Container.App.Docker properties:... capabilities: - Endpoint 1..N HTTP RESTful endpoint, single entry Scaling Policy LoadBalancing Policy my_docker_lambda_fx2 tosca.nodes.Container.App.Docker properties:... capabilities: - Endpoint 1..N

6. 6 db_cluster Cluster type: tosca.groups.Root members: [ mongo ] capabilities: LoadBalancing: Router:... my_docker_elasticsearch tosca.nodes.Container.App type: tosca.groups.Root properties: role:... my_docker_logstash tosca.nodes.Container.App type: tosca.groups.Root properties:... my_docker_kibana tosca.nodes.Container.App type: tosca.groups.Root properties:...

7. 7 © 2015 IBM Corporation Expressing Cluster Semantics A A B B C C D D 1:2 1:3 4:1 6:1 Placement_weight s: R1=2, R2=2, R3=1 Placement_weight s: R1=2, R2=2, R3=1 Placement_weights : R1=2, R2=2, R3=3 Placement_weights : R1=2, R2=2, R3=3 Scaling_ratio: 2:1 Max(A) = 4000 Scaling_ratio: 2:1 Max(A) = 4000 Composite lifecycle: deploy, undeploy, start, stop, update Scaling_limit: 3000 Placement_zon es: R1,R2, R3 Scaling_limit(A): 1000 Scaling_limit: 4000 Min instances: 8 Scaling_limit: 4000 Min instances: 8 Scaling (limit): 10000 Min instances: 24 … Scaling (limit): 10000 Min instances: 24 … Scaling_strategy: auto 2:1 Constraints built-in to the nodes should be inside the nodes but can’t fit in this diagram Unary constraint on node Binary constraint mapping connectivity from source to target Ways to express: 1.Topological policy applied to the relationship from A to B) 2.Requirement in the relation Binary constraint for ration of a pair of node instances A.1 -> B.1, B2 A.2 -> B.3, B.4 … A.1 -> B.1, B2 A.2 -> B.3, B.4 … Composite lifecycle Node external policy Node internal policy

8. 8 © 2015 IBM Corporation Expressing Cluster Semantics A A B B C C D D 1:2 1:3 4:1 6:1 Placement_weight s: R1=2, R2=2, R3=1 Placement_weight s: R1=2, R2=2, R3=1 Placement_weights : R1=2, R2=2, R3=3 Placement_weights : R1=2, R2=2, R3=3 Scaling_ratio: 2:1 Max(A) = 4000 Scaling_ratio: 2:1 Max(A) = 4000 Composite lifecycle: deploy, undeploy, start, stop, update Scaling_limit: 3000 Placement_zon es: R1,R2, R3 Scaling_limit(A): 1000 Scaling_limit: 4000 Min instances: 8 Scaling_limit: 4000 Min instances: 8 Scaling (limit): 10000 Min instances: 24 … Scaling (limit): 10000 Min instances: 24 … Scaling_strategy: auto 2:1 Constraints built-in to the nodes should be inside the nodes but can’t fit in this diagram Unary constraint on node Binary constraint mapping connectivity from source to target Ways to express: 1.Topological policy applied to the relationship from A to B) 2.Requirement in the relation A.1 -> B.1, B2 A.2 -> B.3, B.4 … A.1 -> B.1, B2 A.2 -> B.3, B.4 … Composite lifecycle Node external policy Node internal policy Cluster Composition (Topology) Members A.1 -> B.1, B2 A.2 -> B.3, B.4 … A.1 -> B.1, B2 A.2 -> B.3, B.4 …

9. 9 © 2015 IBM Corporation Cluster1Cluster1 Composition, Reuse, and Recursion A A B B C2 ? D D Composite lifecycle: deploy, undeploy, start, stop, updated Members C3 ? A1 Service Template C5 Z Z A A Service Template ?

10. 10 © 2015 IBM Corporation Cluster1Cluster1 Composition, Reuse, and Recursion A A B B C2 ? D D Composite lifecycle: deploy, undeploy, start, stop, updated Members C3 ? A1 Cluster Service Template Consumed as C1 C5 Z Z A A Service Template C1

11. 11 © 2015 IBM Corporation Cluster1Cluster1 Composition, Reuse, and Recursion A A B B C2 D D Composite lifecycle: deploy, undeploy, start, stop, updated Members C3 A1 Service Template C5 Z Z A A Service Template ? ?

12. 12 tosca_definitions_version: tosca_simple_yaml_1_0 topology_template: description: Template of a database including its hosting stack. inputs: lb_alg: type: string db_password: type: string # other inputs omitted for brevity node_templates: # deprecate ‘groups’ in service template cluster: type: tosca.groups.Cluster.LambdaNodeJS # Just a naming convention, the type hierarchy expresses the semantics members: [node_js_container] # short hand relation notation which can be used for host also node_js_container: type: tosca.nodes.Container.Docker.NodeJS # details omitted for brevity node_types: tosca.groups.Cluster.LambdaNodeJS: capabilities: members: [tosca.nodes.Container.Docker.NodeJS] mem_size: 64MB.. 1.5TB n_cores: 1.. 4 load_balancing: distribution: random, nearest min_instance_lifetime: 30 secs min_active_instances: 100 max_active_instances: 600 lamba_inject_endpoint: S3 URL to lambda artifact interfaces: # Cluster manager can export interfaces for client operations like any other node type tosca.nodes.Container.Docker.NodeJS: capabilities: mem_size: 256MB n_cores: 4 artifact: docker image interfaces: # can export interfaces for unique lifecycle operations Cluster issues: Members defines the kind of nodes provided by the cluster Members is a shortcut relation. Would be nice to make this a general feature so new shortcut relations don’t have to be hardcoded. Host can also benefit from this. Assumption that LB provides endpoint and algorithm which is inconsistent with current spec, but this is not required for all clusters Lambda artifacts: includes all code (no library references) version of runtimes and other framework dependencies