2013 04-specs-camp-tosca-heat-brooklyn

CAMP, TOSCA, and Heat:Three Sides of a Coin

Alex Heneveld / @ahtweetin // April 2013

© 2013 Cloudsoft Corporation

Agenda

• CAMP• An API to facilitate portability and PaaS adoption • “a generic application and platform management API that is language,

framework, and platform neutral”

• TOSCA• A description format to enable portable implementations • “a language to describe [...] semi-automatic creation and management

of application layer services [as] components and their relationships”

• Heat• Brooklyn• ... and a DSL !

2

© 2013 Cloudsoft Corporation 3

OasisCAMP

www.cloudspecs.org

Cloud Application Management Platform

http://www.oasis-open.org/committees/camp/

http://www.cloudspecs.org

http://www.cloudspecs.org




CAMP Key Concepts

• ComponentTemplates are pieces available in the Platform• PlatformComponentTemplates are supplied by the platform —

for instance a Database or a Web Server Cluster• ApplicationComponentTemplates are artifacts uploaded —

a WAR file, database schema, or script file• Requirement and Capability instances determine the wiring

• AssemblyTemplates are the apps available• at runtime, instantiated to make Assembly instances

(comprised of ApplicationComponents and PlatformComponents)• Sensors and Operations available on all of these

• The Platform Deployment Package (PDP) defines new AT’s• a ZIP file POSTed by the consumer• containing app artifacts and a descriptor file specifying the components

and their requirements — in a way that the Platform can then wire up

4

GET /camp/1.0/


CAMP REST/JSON

5

{ "uri": URI, "name": "Web SuperPaaS", "type": "Platform", "tags": [ String, + ], ? "assemblyTemplates": [ Link + ], ? "assemblies": [ Link + ], ? "platformComponentTemplates": [ Link + ], ? "capabilities": [Link + ], ?}

PLATFORM resource

{ "uri": URI, "name": "JEE AppServer tier plus SQL DB", "type": "AssemblyTemplate", "requirements": [ Link + ], ? "applicationComponentTemplates": [ Link + ], ? "platformComponentTemplates": [ Link + ], ?}

ASSEMBLY TEMPLATE resource

GET


OasisTOSCA

http://www.oasis-open.org/committees/tosca/

Topology and Orchestration Specification for Cloud Applications



Modeling Topologies with TOSCA Service Topologies are described using the TOSCA “Meta-model”:

Artifacts Describe Installables and Executables required to

instantiate and manage a service. Currently, they include:

Implementation Artifacts: – Executables or Plans that implement a Node’s

or Relationship’s Operations (e.g. a Bash script) Deployment Artifacts:

– Installables of the components (e.g. a TAR file)

A service’s Topology Model is included in a TOSCA Service Template which is packaged and shared, along with all dependent artifacts, as a TOSCA Cloud Service Archive (CSAR)

Service Templates Group the nodes and relationships that make up

a service’s topology – Allowing modeling of sub-topologies

Service Templates “look like nodes” enabling: Composition of applications from one or more

service templates Substitution of abstract Node types with

available service templates of the same type

Nodes Represent Components of an application or service

and their Properties. Example nodes include: – Infrastructure: Compute, Network, Storage, etc. – Platform: OS, VM, DB, Web Server, etc. – Granular: functional Libraries, Modules, etc.

Include Operations which are the management functions for the node – e.g. deploy(), start(), stop(), connect(), etc.

Export their dependencies on other nodes as Requirement and Capabilities

Relationships Represent the logical Relationships between

nodes – e.g. “hostedOn”, “connectsTo”, etc.

Describes the valid Source and Target nodes they are designed to couple – e.g. source “web application” node is designed

to “connectTo” a target “database” node Have their own Properties and Constraints


TOSCA Key Concepts

7

Slide origin: IBM


TOSCA Example

8

<Definitions id="PayrollDefinitions" targetNamespace="http://www.example.com/ste" xmlns:pay="http://www.example.com/ste/Types"> <Import namespace="http://www.example.com/ste/Types" location="http://.../PayrollTypes.tosca" importType=" http://docs.oasis-open.org/tosca/ns/2011/12"/>

<ServiceTemplate id="Payroll" name="Payroll Service Template"> <TopologyTemplate ID="PayrollTemplate"> <NodeTemplate id="Payroll Application" type="pay:ApplicationNodeType"> <DeploymentArtifacts> <DeploymentArtifact name="PayrollEAR" type="http://..../CSARref"> EARs/Payroll.ear </DeploymentArtifact> </DeploymentArtifacts> </NodeTemplate>

<NodeTemplate id="Application Server" type="pay:ApplicationServerNodeType"> <DeploymentArtifacts> <DeploymentArtifact name="ApplicationServerImage" type="http://.../AMIref"> ami-edf2cf99 </DeploymentArtifact> </DeploymentArtifacts> </NodeTemplate>

<RelationshipTemplate id="deployed_on" type="pay:deployed_on"> <SourceElement ref="Payroll Application"/> <TargetElement ref="Application Server"/> </RelationshipTemplate> </TopologyTemplate> </ServiceTemplate></Definitions>

Slide origin: TOSCA Spec

http://www.example.com/ste/Types




http://www.example.com/ste/Types/PayrollTypes.tosca

http://www.example.com/ste/Types/PayrollTypes.tosca

http://docs.oasis-open.org/tosca/ns/2011/12

http://docs.oasis-open.org/tosca/ns/2011/12

http://www.example.com/ns/tosca/2011/12/DeploymentArtifactTypes/CSARref

http://www.example.com/ns/tosca/2011/12/DeploymentArtifactTypes/CSARref

http://www.example.com/ns/tosca/2011/12/DeploymentArtifactTypes/AMIref

http://www.example.com/ns/tosca/2011/12/DeploymentArtifactTypes/AMIref


CAMP+

TOSCA


CAMP+

TOSCA=

API+

impl


CAMP+

TOSCA=

OpenApp

Platform


Concept Alignment

12

TOSCA CAMP

CSARdescribes what to deploy

PDPwraps CSAR, gives API to install

NodeTemplate, TopologyTemplatethe heart of TOSCA — the orchestration to build them

PlatformComponent(Template)an API for managing — but silent abouthow they are built and where they come from

ServiceTemplate Assembly(Template)

ArtifactTemplate ApplicationComponent(Template)

Requirements and Capabilities Requirements and Capabilities

Relationships Requirement fulfilment

Plans and Policies more PlatformComponent(Template)s

Properties and Operations Attributes, Sensors, and Operations


OpenStackHeat

http://wiki.openstack.org/Heat




Heat

• We all know Heat (and that warm feeling it gives us), but one brief view:

• Vocabulary:• Resources are items natively available from OpenStack

• Stacks are composites of these resources and/or other stacks

• Has:• API — proprietary but isomorphic to a subset of CAMP

• DSL — currently based on AWS CloudFormation but evolving

14


ProjectBROOKLYN

http://brooklyncentral.github.com/

http://brooklyncentral.github.com




16

Brooklyn has been doing this kind of stuff over in Java-land.





17

Complex stuff too!



03/26/13Strictly Confidential © 2013 Cloudsoft Corporation

Active Modelling and Management

18

Location

OS

OS

OS

… OS

…JBoss7Server

NGINX

MySQL

JBoss7Server

+

Auto Scaler Policy[targets]

…

MyWebCluster

ControlledDynamicWebAppCluster

DynamicWebAppCluster

JBoss7Server

NGINX

MySQL

JBoss7Server

Some good (and bad) practices can be learned!


Java Library

public class MyWebCluster extends AbstractApplication implements MyWebClusterConstants { @Override public void init() { MySqlNode mysql = ...; ControlledDynamicWebAppCluster web = ...;

web.addEnricher(HttpLatencyDetector.builder().url(ROOT_URL). rollup(10, SECONDS).build());

web.getCluster().addPolicy(AutoScalerPolicy.builder(). metric(REQUESTS_PER_SECOND_IN_WINDOW_PER_NODE). metricRange(10, 100).sizeRange(2, 5).build());

addEnricher(SensorPropagatingEnricher.newInstanceListeningTo(web, ROOT_URL, REQUESTS_PER_SECOND_IN_WINDOW, REQUEST_LATENCY_IN_SECONDS_IN_WINDOW)); }}

http://web.addEnricher

http://web.addEnricher

http://web.getCluster

http://web.getCluster


they all need a niceDSL

https://wiki.openstack.org/wiki/Heat/DSL/

Conclusion

https://wiki.openstack.org/wiki/Heat/DSL

https://wiki.openstack.org/wiki/Heat/DSL

Technology

2013 04-specs-camp-tosca-heat-brooklyn