OverviewandupdateThursday, 23March,2017

MattRutkowskiIBMSTSM,CloudOpenTechnologiesEditor, Co-Chair, SimpleProfileWG,

PresentingonbehalfoftheTOSCATC:

An important Open standard, that is enabling a unique Cloud eco-systemsupported by a large and growing number of international industry leaders…

TOSCA uses a domain-specific language (DSL) to define interoperable descriptions of :

• Cloud applications, services, platforms, infrastructure and data components, along with their relationships, requirements, capabilities, configurations and operational policies…

• …thereby enabling portability and automated managementacross cloud providers regardless of underlying platform or infrastructure thus expanding customer choice, improving reliability and time-to-value while reducing costs.

2

incorporatesbothData andInformationModel featuresandconcepts…

…butbringsunique orchestration concepts focusinLifecyclemgmt.andState

InformationModelsTypically,usedtomodelaconstraineddomainthatcanbedescribedbyaclosedsetofentity

types,properties,relationships andoperations.

DataModelsTypically,describethestructure(format),enablingmanipulation (viainterfaces)ofthedatastoredindatamanagementsystemsassuring integrity.

• Topology• Composition• Requirements- Capabilities• State(Nodes,Relationships)• Lifecycle (Management)• Policy

IntentModelAdds:

TOSCAisanIntentModel whichisdeclarative(integrationpointsforimperative)

• Structure• Format• interfaces

• Types,Relationships• Properties• Operations

ü TOSCAiscanworkwithimperativescripts(e.g.,Ansible,Chef,Bash,Ant,etc.)

ü TOSCAcanincludeotherdatamodels(e.g.,JSON,YANG)

Tier(GroupType)

TOSCAisusedfirstandforemosttodescribethetopologyofthedeployment view forcloudapplicationsandservices

4

source_resource

Node_Type_A

target_resource

Node_Type_B

Requirement

connect_relationship

ConnectsToCapability

Nodes - aretheresourcesorcomponentsthatwillbematerializedorconsumedinthedeploymenttopology

Relationshipsexpressthedependenciesbetweenthenodes(notthetraffic flow)

ü Nodetemplates todescribecomponentsinthetopologystructure

ü Relationshiptemplates todescribeconnections,dependencies,deploymentordering

Requirement- CapabilityRelationshipscanbecustomizedtomatchspecificsourcerequirementstotargetcapabilities

GroupsCreateLogical,ManagementorPolicygroups(1ormorenodes)

5

TOSCAServiceTemplate(container)ApplicationTier

(container)

WebServer(container)

WebApp

PHPModule

DatabaseTier(container)

DBServer(container)

Database

ServiceTemplatesprovidethe“container”toexchangeandreuse topologies:• Reusablemodels extendinvestmentsbymakingiteasytocomposemorevaluable

andcomplexappsfromexistingapps• Determines dependencyboundaries tomaximize parallelism ofdeployments• Models (dependencies) canbevalidatedbyautomation toensureapplication-aware,

policy-alignedconfiguration,deploymentandoperationalsemantics

Containm

ent

Connectivity

Example:asimple,2-TierCloudapplicationexpressedinaTOSCAServiceTemplate

ApplicationTier(container)

DatabaseTier(container)

6

Logging/MonitoringTier(ELK)

nodejs

WebServer

app_server

Compute

paypal_pizzastore

WebApplication

collectd

logstashSoftwareComponent

Requirements

Container

Capabilitieslog_endpoint

logstash_server

Compute

CapabilitiesContainer

elasticsearchSoftwareComponent

RequirementsContainer

Capabilitiessearch_endpoint

elasticsearch_server

Compute

Capabilities

kibanaSoftwareComponent

Requirements

Container

kibana_server

Compute

Capabilities

search_endpoint

ConnectsTo

HostedOn HostedOn HostedOn

ConnectsTo

mongo_dbms

DBMS

mongo_server

Compute

mongo_db

Database

rsyslog

search_endpoint

ContainerContainer

ConnectsTo

Example:ConnectaLogging/MonitoringServicecomposedofElasticSearch,LogStashandKibana(ELK)

Enablingthedescriptionofcomplex,multi-tier(hybrid)Cloudapplications

TOSCAServiceTemplate

Storage

Compute1

DB

Compute2

App

Network

ScalingPolicy

§ TOSCA’sdefinesNormativeTypes fordifferentdomains,forexample:ü Forportability,TraditionalIaaS,

ApplicationTypesweredefinedü e.g.,WebServer,Database,Compute,Block

Storage,Network

ü Expandedtoinclude“PaaS”(Containers)ü Workingonnew“Abstract”Compute,

StorageTypesforv1.2ü AllowforvaryingComputehosts,notso“IaaS”

§ CloudApplication’sdeclarativemodelledfromthesenormativetypes…

§ …CanbeunderstoodbyanyCloudProvider

unfulfilledApplication Requirements

canbeexportedforOrchestratorstofulfill

Templatesinclude(orreference)allnecessaryconfigurationandInfrastructurerequirements

TOSCAapplications,usingnormativetypes,areportabletodifferentCloudinfrastructures

TOSCAMeta-Model NormativeTypes

Nodes• Properties• Attributes

Relationships• Properties• Attributes

Capabilities

Interfaces(Operations)

Groups

Policies

Requirements

Interfaces

compo

sedfrom

basedup

on

tosca_definitions_version: # Required TOSCA Definitions version stringdescription: <template_type_description>metadata: # Optional (and extensible) metadata keyname: value pairs

# Some convenience keys left out for this example…

repositories: # list of external repository definitions which host TOSCA artifactsimports: # ordered list of import definitions

# Type defintions artifact_types: # list of artifact type definitionsdata_types: # list of datatype definitionscapability_types: # list of capability type definitionsinterface_types # list of interface type definitionsrelationship_types: # list of relationship type definitionsnode_types: # list of node type definitionsgroup_types: # list of group type definitionspolicy_types: # list of policy type definitions

topology_template:# topology template definition of the cloud application or service

ThePortable“file”thatdefinesa(composable)Service

Note:Onlyrequiredelementisthe“tosca_definitions_version”thismeansthat…• Youcancreatetemplatesthatjustdefine“reusabletypes”for“import”intootherServiceTemplates

topology_template:description: <template_description> inputs: <input_parameter_list>outputs: <output_parameter_list>node_templates: <node_template_list>relationship_templates: <relationship_template_list>groups: <group_definition_list>policies:

- <policy_definition_list>workflows: <workflow_list>

# Optional declaration that exports the Topology Template # as an implementation of a Node Type.substitution_mappings:

node_type: <node_type_name>capabilities:<map_of_capability_mappings_to_expose>

requirements:<map_of_requirement_mapping_to_expose>

TheTopology whereyournode-relationship graphisdeclared…ThisiswhattheTOSCAOrchestratordoesits“best”todeploy(with”desiredstate”andmaintainto(operational) policy

AServiceTemplatecanequalaNode(Template)viasubstitutionmappingsusedindicatetheServiceTemplate’sTopologyimplementssomeNodeType(withCapabilities)… whichcanbeusedto“fulfill”anabstractRequirementinanotherServiceTemplate(atdeployment)!!!

DeclarativeWorkflow

• Introducedinv1.1• DesignedtoSupportcomplexinstalls/

Configurations.• Preserveinvestmentinlegacyscripts• IntegrateswithTOSCAOrchestrator

(operations)• Careful totakeoveratknownstate

andreturntoknownstate

AnalyticsService

(Topology)

CloudApplication(Topology)

Orchestrators can “substitute” for abstract nodes…… as long as all declared “requirements” are met:

• Monitoring Service can be substituted in Cloud Application • Analytics Service can be substituted in Monitoring Service

AbstractnodesinoneTOSCAtopologycanbesubstitutedwithanothertopology

MonitoringService(Abstract)

JavaApplication

WebApplication

Server

SQLDatastore

MonitoringService(Topology)

Collector

Logger

MonitoringFramework

AnalyticsService(Abstract)

AnalyticsEngine

HadoopServiceTemplate1

ServiceTemplate2

ServiceTemplate3

AnatomyofaNodeType(grammar)withfocusonRequirements&CapabilityDefinitions

<capability_type_name>:derived_from: <parent_capability_type_name>version: <version_number>description: <capability_description>properties:

<property_definitions>attributes:

<attribute_definitions>valid_source_types: [ <node type_names> ]

RequirementdefinitionsareexpressedusingCapabilityTypes• TherearenoRequirementTypesinTOSCA

<node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata:

<map of string> description: <node_type_description> attributes:

<attribute_definitions> properties:

<property_definitions> requirements:

- <requirement_definitions> capabilities:

<capability_definitions> interfaces:

<interface_definitions> artifacts:

<artifact_definitions>

<requirement_definition_name>: capability: <capability_type_name>node: <node_type_name>relationship: <relationship_type_name>occurrences: [ <min>, <max> ]

<capability_definition_name>:type: <capability_type>description: <capability_description>properties:

<property_definitions>attributes:

<attribute_definitions>valid_source_types: [ <node type_names> ]

Foo:derived_from: Rootversion: 1.0description: “My foo”properties:

bar: stringattributes:

reason: string

12

Nodesexpresstheir“requirements”foranotherNode’s“capabilities”• Usingwell-known(published)CapabilityTypesandtheirProperties

NodeARequirements

NodeBCapabilities

NodeA“IhavearequirementaNodewithCapability

Type’Foo’“

NodeB“IhaveaCapability ofCapability Type’Foo’“

TOSCAServiceTemplate

… again,therearenoRequirementTypesinTOSCA

“import:Foo” “import:Foo”

SharedDefinitionFoodefinedinaService

Templateandimportedbyboth

13

Property(values)reflect“desired”state(configuration)• Pre-deployment(desiredstate)

• Reflectsdesired/optimalconfigofservicecreator(submitter)• IncludesPropertieswithinaNodeType’slistedCapabilities(CapabilityTypes)

• TOSCAOrchestratorsimperativeisto”getitrunning”• Unlessmarkedexplicitlyas“required”• TOSCANormativeNodeTypes~99%ofallPropertiesare“optional”• Computeexample…

Attribute(values)reports“actual”state• Post-deployment(actualstate)

• Reflects“bestmatch”Orchestratorcouldachieveontargetplatform

ALLPropertieshaveimplicitAttributes• Evenifnotexplicitlydeclared inNodeTypedefinition(Requirementsincev1.0)• Recognitionofan“instancemodel”accessiblebyNodes(templates)withinaServiceTemplateduring

Orchestration(via“getAttribute()”intrinsic function)

Example:TOSCAapplicationsareportabletodifferentCloudinfrastructures

Application Requirements

TOSCAOrchestration

TOSCAServiceTemplate

Storage

Compute1

DB

Compute2

App

Network

ScalingPolicy

CloudProviderC

CloudProviderA

CloudProviderB

byexpressingapplicationRequirements…

independentlyfromcloudproviderCapabilities…

&OptimizationAutomaticMatching

Infrastructure Capabilities

OrchestratorsconcernthemselvesdealingwithdisparatecloudAPIs 14

Capabilities

Requirements

<data_type_name>: derived_from: <existing_type_name>version: <version_number>metadata:

<map of string>description: <datatype_description>constraints:

- <type_constraints> properties:

<property_definitions>

(Normative)DataTypescanbedefinedinProfiles

• AllTOSCADataTypesshouldderivedfromTOSCARootDataType(tosca.datatypes.Root)• TOSCAv1.0definesasmallsetofnormativetypes(foroptionalreuse)…

• tosca.datatypes.Credential• SupportsHTTPBasicAuth,X-Auth-Token,OAuth,OpenStackSSHkeypair,etc.

• tosca.datatypes.TimeInterval• YAMLISO8601formattodeclarethestartandendtimes (usefulforPolicy/Monitoring)

• tosca.datatypes.NetworkInfo,PortInfo,PortSpec• TypicalIaaSNetworkdata(compatiblewithOpenStack)

TheseDataTypescanbeusedonPropertiesIncludes:• TypeDerivation

(Inheritance)• Versioning

my_resource_name

My_Resource_Type

Lifecycle.Standard

create

configure

start

stop

delete

Node Lifecycle

Ope

ratio

ns

Implementations (e.g., imperative scripts) can be bound to operations.

source_resource

Type_A

A

target_resource

Type_B

B

my_relationship

ConnectsTo

Lifecycle.Configure

pre_config_target

post_config_target

add_target

remove_target

pre_config_source

post_config_source

add_source

remove_source

Operations

The Orchestrator moves the nodes through their Lifecycle States by executing their LifecycleOperations in topological order• Orchestrators can work to deploy nodes in parallel based upon node relationships

Relationship LifecycleNodes havetheirownLifecycle

Operations whichareinvokedinordertoachieveatargetstate

Relationships alsohavetheirownLifecycleOperationstoconfigureorallocateandde-configureordeallocateNode relatedresources

TOSCAmodelshaveaconsistentviewofstate-basedlifecycle

• Topicsinthenear-termpipeline• EachhasdedicatedWorkGroupsunderTOSCATC• Nospecificversion commitments/impacts toSimpleProfileinYAML,eachWGhasitsowntimeline• Somespecific proposalsmayintroducesome“enablements” intov1.2CSDpublic drafts

• Interoperability(Conformance)– Dedicatedworkgroup• Goal:Conformance testsuiteforv1.0;includes testsforeachsectionofSimpleProfilev1.0specification.

• EachtestisaTOSCAServiceTemplateswithmetadatadescribingtestusingtheOASISTest-Assertion(TAG)Standard• Workunderwaytopublish innewGitHub repo.,announcement (Sept2016)

• InstanceModel– Dedicatedworkgroup• Goal:newschemaforanInstanceModel(reuseexistingschemawherepossible)

• DiscussingAPIpotentiallyenablingcapture,export andmanagement ofdeployed application

• Monitoring– Dedicatedworkgroup• Goal:Createnormativeeventtypesforbasicoperationalevents

• FocusoneventstypesforHealth,Scaling &Performance• Support basic“Red-Yellow-Green”andPercentage-basedmonitoringfordashboards

Version1.0• Official OASISStandard;12December2016

Version1.1• TOSCATCCommitteeSpec.(final) March2016

• PromotedfromCSD02,publicdraftpublished12January2017(completed60dayreview)

Version1.2• Publicdraft:CSD01- TargetApril30th,2017features“NFVProfile”enablement

• ArtifactProcessors(AP)as1st classcitizens• CompleteSubstitutionMapping–

• Allowfullmappingofallparsofnode(keys)• TOSCAOrchestratorsClearrulesforprocessingartifacts(inconjunctionw/APs)• SupportbasicBPEL/BPMNasrecognizedartifacttypes,withexamples• AllowNodeTypesubclassestofurtherconstrainparenttypes

• Increaseconstraints onproperties• Markproperties andAttributes “status”asdeprecated• Contrain (orturn off)Requirements andCapabilities (usingOccurrences fieldsetto[0,0]

• PermitTOSCAOrchestratorstomatch”abstract”nodetypeswithconcreteimpls.(inServiceTemplates)usingPropertyvalues• ConverselythisallowsServiceTemplateauthorstodeclaretheir implementations support onlycertainProperty values

• Enables“SelectionPattern” forNFV• Publicdraft:CSD02– TargetJune30th,2017

• AnyoutstandingNFVProfileitems• Event-Condition-ActionModel:Add“Monitorable”CapabilityTypetoTOSCARootNode+OperationalEventTypes

• Eventscould thenpossiblybeaddedtoPolicyTypes(aspartofthe“Action”)• Discussproposalsintroducedto:

• Support UIs(Property masking,PropertyGrouping)• Support JSONasanapproveddatatype• Support Complex Property(Input)validation(RevisitRegex)• Support OutputsofOperations(Errors)

18

19

• TOSCATechnicalCommittee (TC)PublicPage(TCapprovedupdatesondocuments,strategy,andmore)

—https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca

• OASISTOSCALinkedInGroup: (latestnews,communityandeco-systemupdates,etc.Joinnowtostay informed!)— https://www.linkedin.com/groups/8505536

• OASISYouTubeChannel, TOSCAPlaylist—https://www.youtube.com/user/OASISopen , http://bit.ly/1BQGGHm

• Contact theTechnicalCommitteeCo-Chairs (alsopartofTOSCATCPanel):– PaulLipton,paul.lipton@ca.com; JohnCrandall,jcrandal@brocade.com

Q&A

v1.0includesthegroundworkforPlacement(Affinity),ScalingandPerformancePolicies‒ OrchestratorscanevaluateConditions basedonEvents thattriggerAutomaticorImperativeActions

Policiescanbedeclaredindependentlyandttached tovariouspointsinyourmodels1. ThatcanbeattachedtoInterfaces orspecificOperations,2. Nodes and3. Groups ofNodes

my_app_1

Compute

Capabilities

Container

...Lifecycle

create

configure

...

Policy• Type• Event, Condition• Action

my_scaling_group

backend_app

Compute

Policy• Type• Event, Condition• Action

my_database

Computeweb-app

ComputePolicy• Type• Event, Condition• Action

1

2

3

Scaling

“Policiesarenon-functionalRequirementsindependentofnodes”