1. TOSCA SugarCRM Deployment
technical detail discussion TOSCA Interop SC

2. 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]

3. 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

4. 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

5. 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)

6. 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="
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.

7. 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_)

8. 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