Script Invocation Conventions TOSCA Interop SC

Introduction / Background Current interop use case SugarCRM provides simple scripts as Implementation Artifacts for lifecycle operations of Node Types Conventions have to be defined to allow for interoperable invocation of those scripts in different TOSCA implementations – References to actual scripts in CSAR – Parameter passing from model to script – … Note: bindings to several script languages have to be defined. For now, only bash scripts are used, so we concentrate on a bash binding. 2

Script Artifact Definitions Non-normative Artifact Type “ScriptArtifact” defined in interop use case  Has to be documented; candidate for normative definition in TOSCA vNext – ScriptLanguage: specifies the used script language  impact on invocation convention, parameters passing, etc. – PrimaryScript: specifies the “entry script” to be invoked in cases where multiple files are referenced by an ArtifactTemplate (e.g. is main script brings with it additional helper or library files) ArtifactReferences element uses Ant fileset like notation – reference attribute can specify a file or directory – If reference points to a directory, files in the directory to be referenced by the ArtifactTemplate are specified thru include and exclude patterns – Relative reference URIs in ArtifactTemplate elements are interpreted relative to the CSAR root directory <ArtifactTemplate id="at-c1ab1a58-91f1-49ec-a3e0-57f46e3d72e1“ type="ns1:ScriptArtifact"> <ns1:ScriptArtifactProperties xmlns:ns1=" xmlns=" sh scripts/MySQL/configure.sh 3

Invocation Conventions for bash scripts Parameters are passed to script as environment variables – Script can access parameters by name using $ notation Scripts in current interop example are supposed to be executed on the target environment (i.e. VMs created during service instantiation) Invocation mechanism – Make script (incl. potential helper files) available on target environment – Create a new bash – Set all parameters to be passed to script as environment parameters – Invoke script – Process return code; read out potential return parameters the script may have written to environment variables 4

Parameter conventions for scripts of Node Type Operations Pass all properties of the Node instance (instantiated Node Template) to script as environment variables Pass special parameter like “PublicIP” as environment variables – Denotes the public IP address of the VM on which the Node is deployed (i.e. avoids having to define a PublicIP property for each Node Type) Example: configure.sh of SugarCRMApplication – NodeType SugarCRMApplication defines parameters AdminUser, AdminPassword, etc. – Script can access parameters like $AdminUser $AdminPassword … 5

Parameter passing for scripts of Relationship Type Operations Pass all properties of the Relationship instance (instantiated Relationship Template) as environment variables – Accessible by script as $ Pass all properties (and special properties like PublicIP) of the source Node instance of the relationship as environment variables with prefix “Source_” – Accessible by script as $Source_ Pass all properties (and special properties like PublicIP) of the target Node instance of the relationship as environment variables with prefix “Target_” – Accessible by script as $Target_ Example: connectToDatabase.sh of MySQLDatabaseConnection … sed -i -e 's/YOURDBHOST/'${Target_PublicIP}:${Target_mySqlPort}'/' $ResponseFile sed -i -e 's/YOURDBNAME/'${Target_DBName}'/' $ResponseFile sed -i -e 's/YOURDBUSER/'${Target_DBUser}'/' $ResponseFile … 6