TOSCA SugarCRM Deployment technical detail discussion TOSCA Interop SC

SugarCRM Topology Template SugarCrmApp [SugarCRMApplication] SugarCrmDb [SugarCRMDatabase] connects to depends on PhpModule [ApachePHPModule] hosted on hosted on ApacheWebServer [ApacheWebServer] MySql [MySQL] hosted on hosted on hosted on OsApache [OperatingSystem] OsMySql [OperatingSystem] hosted on hosted on VmApache [Server] VmMySql [Server] hosted on hosted on WebTier [Tier] DbTier [Tier]

Node and Relationship operations RelationshipType “DBConnection” NodeType “Application” R NodeType “Database” C Lifecycle operations (create, configure, start, …) are used by an orchestrator to create and manage components is of type is of type is of type Connector concept Relationship Types declare what endpoints they can connect, and which processing logic they inject to establish a link at runtime NodeTemplate “MyApp” R NodeTemplate “MyDB” C Base Relationship Types HostedOn, DependsOn and ConnectsTo define the base semantics for processing topology models 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 (HostedOn) Process a provider before a client (DependsOn, ConnectsTo) If a component is related to another component, see if relationship injects additional processing logic (e.g. pre-configure endpoint) … a pretty mechanical process

Declarative processing of SugarCRM 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 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 5 DB 4 Web 4 Web 3 DB 3 Web 2 DB 2 Web 1 DB 1 Web 1 create VM DB 1 create VM Web 2 perform base OS config DB 2 perform base OS config run in parallel Web 3 install and configure httpd DB 3 install and configure MySQL Web 4 install and configure php runtime DB 4 create and configure SugarCRM database Web 5 install and configure SugarCRM app, configure database endpoint properties wait for step “DB 4” to complete

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 MySQL on a VM)

Example Deployment Artifact and Implementation Artifact usage <NodeTemplate id="WebServer" type="WebServer"> <Properties> <WebServerProperties> <httpport>8080</httpport> ... </WebServerProperties> </Properties> </NodeTemplate> <NodeType name="WebServer"> </NodeType> <NodeTypeImplementation name="WebServer-rhel-x86_64“ nodeType="WebServer"> <RequiredContainerFeatures> <RequiredContainerFeature feature="os_type">linux</Req...> <RequiredContainerFeature feature="os_distro">rhel</Req...> </RequiredContainerFeatures> <ImplementationArtifacts> <ImplementationArtifact artifactRef="webserver-configure" artifactType="ScriptArtifact" interfaceName="http://.../lifecyle" operationName="configure"/> </ImplementationArtifacts> <DeploymentArtifacts> <DeploymentArtifact artifactRef="webserver-packages" artifactType="OsPackageArtifact"/> </DeploymentArtifacts> </NodeTypeImplemenation> <ArtifactTemplate id="webserver-packages" type="OsPackageArtifact"> <OsPackageArtifactProperties packageType="rpm"> <PackageInformation packageName="httpd"/> <PackageInformation packageName="php"/> </OsPackageArtifactProperties> </ArtifactTemplate> <ArtifactTemplate id="webserver-configure" type="ScriptArtifact"> One NodeType can have multiple implementations, e.g. for different operating systems. Orchestrator selects based on Required Container Features definitions. DeploymentArtifact "webserver-packages " artifactType: OsPackageArtifact packages: [httpd, php, php-cli, php-common, php-mysql, php-xml] Web Server configure ImplementationArtifact "webserver-configure" artifactType: ScriptArtifact script: scripts/WebServer/configure.sh Operating System #!/bin/bash # set listen port of httpd sed –i "s/Listen 80/Listen $httpport" $httpdconfig # more stuff ... Server $httpport accesses a property of the associated NodeTemplate. In this example, configure.sh script is packaged in directory scripts/WebServer in the CSAR containing the TOSCA template definition.

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: preConfigureEndpoint, postConfigureEndpoint 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 PublicIP, PrivateIP, HostName, 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, PublicIP, PrivateIP, HostName, FQDN of the VM where the source node is hosted (prefixed with Source_) Plus properties, PublicIP, PrivateIP, HostName, FQDN of the VM where the target node is hosted (prefixed with Target_)

Example processing flow including node and relationship operations install install postConfigureEndpoint configure configure start postConfigureEndpoint start Node2.install Node2.configure Node2  postConfigureEndpoint Node2.start Node1.install Node1.configure Node1  postConfigureEndpoint Node1.start