OASIS TOSCA. and how it could fit into OpenStack Heat. OpenStack Design Summit, April 15 th Thomas Spatzier, IBM

Transcription

1 OASIS TOSA and how it could fit into OpenStack Heat OpenStack Design Summit, April 15 th 2013 Thomas Spatzier, IBM

2 Agenda TOSA Overview and Examples TOSA oncepts Explained About Encoding Discussion: TOSA and Heat 2

3 Properties Properties What is TOSA? Topology and Orchestration Specification for loud Applications A language for defining Service Templates including a Topology Template describing the structure of a service elationship Template Service Template Topology Template type for Node Types apabilities equirements Interfaces Scripts Installables Definition of building blocks for services along with the implementation artifacts for manageability operations type for Images and the definition of deployment artifacts for components Node Template including the definition of plans for orchestrating the application Plans elationship Types Interfaces Definition of possible links between components Packaging format (SA) for packaging models and all related artifacts. loud Service Achive (SA) 3

4 TOSA T Members 3M ActiveState Axway A Technologies enturylink isco itrix loudsoft EM Fujitsu Google HP IBM Huawei Jericho Systems NetApp Nokia Siemens Pricewaterhouse Primeton ed Hat SAP Software AG VE Vnomic WSO2 Zenoss 4

5 1 st Interop Example: SugarM SugarMApp SugarMDB depends on [WebApplication] connects to [MySQLDatabase] PHPModule [ApacheModule] hosted on hosted on installed on Apache MySQL [ApacheWebServer] [MySQL] hosted on hosted on LinuxOS4Web LinuxOS4DB [OperatingSystem] [OperatingSystem] hosted on hosted on Server4WebTier Server4DBTier [Server] [Server] 5

6 Templates Types Language TOSA v1.0 spec Using TOSA to model Applications Node Type elationship Type Implementation Artifact Deployment Artifact MySQL Database MySQLDBontainer eq. MySQL LinuxOS eq. start.sh start.sh configure.sh PMs: mysql mysql-server MySQLDBonnection Properties: ontext root: /mycrm SugarMApp [WebApplication] SugarMDB [MySQLDatabase] Properties: DB Name: mysqldb Properties: HTTP Port: 8080 Apache [ApacheWebServer] MySQL [MySQL] Properties: Admin User: myadmin Primary focus for users Orchestrator Deployed Instances 6

7 ole of elationships in Model Processing NodeType Application is of type elationshiptype DBonnection is of type is of type NodeType Database Lifecycle operations (create, configure, start, ) are used by an orchestrator to create and manage components NodeTemplate MyApp NodeTemplate MyDB onnector concept elationship Types declare what endpoints they can connect, and which processing logic they inject to establish a link at runtime Base elationship Types HostedOn, DependsOn and onnectsto define the base semantics for processing topology models Use defined lifecycle operations to deploy and manage each component If a component is related to another component, see if relationship injects additional processing logic (e.g. pre-configure endpoint) Use base relationship types to derive processing order Process a host before a hosted component (HostedOn) Process a provider before a client (DependsOn, onnectsto) a pretty mechanical process 7

8 How is a Topology processed? Use base relationship types to derive component processing order First process a host, then process hosted component First process a component that another component depends on, then process the dependent component First process a component that another component connects to, then process the connecting component For each component Deploy its Deployment Artifacts Invoke lifecycle operations in right sequence (create, configure, start ); their can be no-ops If a relationship contributes logic, inject it into component operation invocations Web 4 Web 5 Web 3 Web 2 Web 1 relationship injects logic DB 4 DB 3 DB 2 DB 1 Web 1 create VM DB 1 create VM Web 2 Web 3 perform base OS config install and configure httpd run in parallel DB 2 DB 3 perform base OS config install and configure MySQL Web 4 install and configure php runtime DB 4 create and configure SugarM database Web 5 install and configure SugarM app, configure database endpoint properties wait for step DB 4 to complete 8

9 ompute Storage ompute Storage ompute Storage equirements & apabilities Some Application Database provider = MySQL version >= 5.5 Database Database Provider arch = x86_64 cpus = 2 mem >= 4GB OS = Linux Some Application size >= 10GB Database provider = MySQL version >= 5.5 equirements can be fulfilled explicitly by other components in the model arch = x86_64 cpus = 2 mem >= 4GB OS = Linux equirements can be fulfilled size by >= the 10GB runtime equirements/apabilities are base for substitutability Some omponent Provider A O Provider B O Provider 9

10 Model omposition Service Template 1 Node Template Service Template 2 Node Template boundary definitions Subsystems can be abstracted in some models. Other models can define details of subsystems. separation of concern, re-use 10

11 Usage Scenarios for Model omposition & Substitution Varying deployment options Layering of models WebApp ustom workload App DB Application Layer WebTier Multiple options of middleware deployments Tomcat MySQL Platform Layer Web Server VM Load Balancer VM Web Server VM 1..* Multiple options of infrastructure configurations VM Network VM Storage Infrastructure Layer Single node web tier Scalable web tier 11

12 About Encoding TOSA is XML The TOSA T decided to use XML and XML Schema as the normative way for defining the TOSA language. But: The important thing about TOSA are the concepts, not the encoding. Alternative encodings (e.g. JSON) can be defined as part of TOSA vnext work. 12

13 Alternative Encoding Example <NodeType name="server"> <PropertiesDefinition element="tbase:serverproperties"/> </NodeType> <xs:schema...> <xs:element name="serverproperties" type="tserverproperties"/> <xs:complextype name="tserverproperties"> <xs:sequence> <xs:element name="numpus" default="1"> <xs:simpletype> <xs:restriction base="xs:int"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="4"/> </xs:restriction> </xs:simpletype> </xs:element> <xs:element name="memory" type="xs:int"/> </xs:sequence> </xs:complextype> </xs:schema> <TopologyTemplate> <NodeTemplate id= MyServer" type="tbase:server"> <Properties> <tbase:serverproperties> <Numpus>2</Numpus> <Memory>4096</Memory> </tbase:serverproperties> </Properties>... </NodeTemplate>... </TopologyTemplate> "NodeType" : { "name" : "Server", "properties" : [ { "name" : "Numppus", "type" : "integer", "options" : [1,2, 4] }, { "name" : "Memory", "type" : "integer", } ]... } "TopologyTemplate" : { "NodeTemplates" : [ { "id" : "MyServer", "type" : "Server", "properties" : [ "Numpus" : 2, "Memory" : 4096 ] },... ],... } 13

14 Now, how could it fit into Heat? It s all about concepts: as longs as a pattern engine s concepts and TOSA are aligned, mapping to TOSA as an external format is straight forward No need to use TOSA as Heat s core format Define a sub-set profile of TOSA that is appropriate for use cases targeted by Heat Define an alternative JSON rendering for TOSA sub-set profile Define a set of base Node- and elationship Types for core OpenStack resources: ompute (Nova), Network (Quantum), Block Storage (inder), Object Storage (Swift) As natively supported types Users do not have to care about defining TOSA types, but can just start defining templates Use implementation to improve and refine the TOSA standard; use standardized concepts to shape implementation 14

15 Learn more about TOSA TOSA Specification, Version 1.0 ommittee Specification 01, 18 March November 2013, TOSA Primer, Version 1.0 ommittee Note Draft (ND) 01, Public eview Draft 01, 31 January 2013, TOSA Implementer's ecommendations for Interoperable TOSA Implementations, Version 1.0 Interoperability Subcommittee, Working Draft 01, ev. 02, 14 January 2013, TOSA Interoperability Subcommittee, SugarM Scenario Sample SA Preliminary Draft SA for Interop. Testing against TOSA v1.0 Specification, 15