TOSCA Sugar CRM Deployment technical detail discussion TOSCA

TOSCA Sugar. CRM Deployment technical detail discussion TOSCA Interop SC

Sugar. CRM Topology Template Sugar. Crm. App [Sugar. CRMApplication] depends on Php. Module Sugar. Crm. Db connects to [Sugar. CRMDatabase] hosted on Apache. Web. Server My. Sql [Apache. Web. Server] [My. SQL] hosted on Os. Apache Os. My. Sql [Operating. System] hosted on Vm. Apache Vm. My. Sql [Server] hosted on Web. Tier Db. Tier [Tier] [Apache. PHPModule] hosted on 2

Node and Relationship operations Relationship. Type “DBConnection” Node. Type R “Application” C is of type Node. Template R “My. App” Base Relationship Types Hosted. On, Depends. On and Connects. To define the base semantics for processing topology models is of type C is of type Node. Template “My. DB” Node. Type “Database” Lifecycle operations (create, configure, start, …) are used by an orchestrator to create and manage components Connector concept Relationship Types declare what endpoints they can connect, and which processing logic they inject to establish a link at runtime • Use defined lifecycle operations to deploy and manage each component • Use base relationship types to derive processing order • Process a host before a hosted component (Hosted. On) • Process a provider before a client (Depends. On, Connects. To) • If a component is related to another component, see if relationship injects additional processing logic (e. g. pre-configure endpoint) … a pretty mechanical process 3

Declarative processing of Sugar. CRM model relationship injects logic • 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 – 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 create VM Web 2 perform base OS config Web 3 install and configure httpd Web 4 install and configure php runtime Web 5 install and configure Sugar. CRM app, configure database endpoint properties run in parallel DB 4 Web 3 DB 3 Web 2 DB 2 Web 1 DB 1 Web 4 • For each component Web 1 Web 5 DB 1 create VM DB 2 perform base OS config DB 3 install and configure My. SQL DB 4 create and configure Sugar. CRM database wait for step “DB 4” to complete 4

Artifacts and automation in TOSCA models • Deployment Artifacts referenced in a TOSCA model represent the “deployable bits” that embody components of a deployment at runtime – Examples: software installables, OS packages (rpm, deb, …), simple files, archives, images for VMs – Deployment Artifacts just get declared in the model and orchestrator implements logic to do automatic deployment • For example, an archive artifact for a tarball might include metadata about target location as well as file path permissions for target location, incl. user/group mappings orchestrator derives corresponding sequence of commands for full deployment flow • Currently supported: File, Archive, User Archive, RPM List, RPM Group List • Implementation Artifacts referenced in TOSCA model represent implementation of operations on components of the model – Examples: scripts, chef automation, executable programs – Implementation Artifacts get executed in context of deployed environment; model parameters (e. g. Node Template properties) and other context information (e. g. hostnames, IP addresses) passed as arguments • Artifact definitions in TOSCA model have a pointer to the actual artifact – In current use cases, typically a relative URL to a file in the CSAR containing the TOSCA model, but could be any URL accessible by the orchestration environment • Deployment Artifacts for a component get deployed before any Implementation Artifacts get executed – Most basic scenarios could be done with Deployment Artifacts only (e. g. rpm based installation of My. SQL on a VM) 5

Example Deployment Artifact and Implementation Artifact usage <Node. Template id="Web. Server" type="Web. Server"> <Properties> <Web. Server. Properties> <httpport>8080</httpport>. . . </Web. Server. Properties> </Properties> One Node. Type can have multiple </Node. Template> implementations, e. g. for different operating systems. Orchestrator <Node. Type name="Web. Server"> selects based on Required Container. . . Features definitions. </Node. Type> Deployment. Artifact "webserver-packages " artifact. Type: Os. Package. Artifact packages: [httpd, php-cli, php-common, php-mysql, php-xml] configure Implementation. Artifact "webserver-configure" artifact. Type: Script. Artifact script: scripts/Web. Server/configure. sh Web Server Operating System #!/bin/bash # set listen port of httpd sed –i "s/Listen 80/Listen $httpport" $httpdconfig # more stuff. . . Server In this example, configure. sh script is packaged in directory scripts/Web. Server in the CSAR containing the TOSCA template definition. $httpport accesses a property of the associated Node. Template. <Node. Type. Implementation name="Web. Server-rhel-x 86_64“ node. Type="Web. Server"> <Required. Container. Features> <Required. Container. Feature feature="os_type">linux</Req. . . > <Required. Container. Feature feature="os_distro">rhel</Req. . . > </Required. Container. Features> <Implementation. Artifact artifact. Ref="webserver-configure" artifact. Type="Script. Artifact" interface. Name="http: //. . . /lifecyle" operation. Name="configure"/>. . . </Implementation. Artifacts> <Deployment. Artifact artifact. Ref="webserver-packages" artifact. Type="Os. Package. Artifact"/> </Deployment. Artifacts> </Node. Type. Implemenation> <Artifact. Template id="webserver-packages" type="Os. Package. Artifact"> <Properties> <Os. Package. Artifact. Properties package. Type="rpm"> <Package. Information package. Name="httpd"/> <Package. Information package. Name="php"/>. . . </Os. Package. Artifact. Properties> </Artifact. Template> <Artifact. Template id="webserver-configure" type="Script. Artifact">. . . </Artifact. Template> 6

Lifecycle operations and invocation context for Implementation Artifacts • Default lifecycle operations for nodes: – install, configure, start, stop, delete – there may be no-ops (leave out operations) – Flow for deploy case: install, configure, start • In case of chef automation, only install operation is used • Default lifecycle operations for relations: – pre. Configure. Endpoint, post. Configure. Endpoint for both source and target – there may be no-ops • Each node operation gets as context all properties of the node (defined in XSD) plus Public. IP, Private. IP, Host. Name, FQDN of the VM where the node is hosted • Each relationship operation gets as context all properties of the relationship (defined in XSD) – Plus properties, Public. IP, Private. IP, Host. Name, FQDN of the VM where the source node is hosted (prefixed with Source_) – Plus properties, Public. IP, Private. IP, Host. Name, FQDN of the VM where the target node is hosted (prefixed with Target_) 7

Example processing flow including node and relationship operations install configure start • • install post. Configure. Endpoint Node 1 Node 2 post. Configure. Endpoint configure start Node 2. install Node 2. configure Node 2 post. Configure. Endpoint Node 2. start Node 1. install Node 1. configure Node 1 post. Configure. Endpoint Node 1. start 8