deployment.xml reference

The deployment.xml configuration file applies to service package deployment.

The deployment.xml file defines:
  • Commands to be run after a service package is deployed.
  • Dependent packages.
  • Environment variables accessible to the package.

The file must be called deployment.xml, and must be included in the service package.

Location

The file must be included at the parent level of the service package; it cannot be in a subdirectory. Only one file can be included for each service package.

Structure

The deployment.xml file includes the following sections:
  • install
  • uninstall
  • packageDependencies
Important: The order of the sections in deployment.xml is important. Changing the order causes errors.

All values in the file are case-sensitive when the service is deployed on Linux®.

Example
<Deployment packageVersioning="true">
    <install>
        <osTypes>
            
            <osType name="X86_64" startCmd="install" timeout="100" successCodes="-1:10"/>
        </osTypes>
    </install>
    <uninstall>
        <osTypes>
            
            <osType name="X86_64" startCmd="uninstall" timeout="34" successCodes="0"/>
        </osTypes>
    </uninstall>
    <packageDependencies>
        <package name="Common"/>
    </packageDependencies>
</Deployment>

header section

Optional.
Table 1.
Attribute Description Default Value
packageName Optional: Name assigned to the service package during deployment. None
packageVersioning Optional: Manages the .v# extension added to the directory name of a package, enabling the administrator to define deployment directories on a compute host. Valid values are:
  • true (or not defined): The .v# extension is added to the package directory name.
  • false: The .v# extension is not added to the package directory name.
    When package versioning is disabled, the package is deployed to a compute host without the .v# extension added to its directory name. Note the following characteristics of this setting:
    • If an existing service package is updated, the repository server (RS) prevents the update.
    • A service package can be removed, but it cannot be re-added with the old name.
    • A consumer subnode and service package cannot have the same name at one level in the consumer tree.

You cannot update the packageVersioning flag once the package has been added to the RS.

true

install section

Optional. Use the install section to configure commands to run after the package is uncompressed on a compute host.

install > osType attributes

Attribute Description Default Value
name Required: Operating system type name.
Commonly used values:
  • X86_64: For a Linux-based 64-bit environment
  • LINUXPPC64LE: For Linux-based, 64-bit PowerPC Little Endian environment

For a complete list of valid values, refer to $EGO_CONFDIR/ego.shared.

None
startCmd Required: Command to run after the service package is copied to a compute host and decompressed.

Specify a path relative to the service package installation directory. For example, if your package contained a subdirectory called scripts with the command you want to invoke called myscript, specify:

./scripts/myscript

Note: If you specify your own script, be aware that the script is executed with umask 002. As a result, any directories and files created by the script are set to the following permissions:
  • 775 for directories (read, write, and execute for the owner; read and execute for others).
  • 664 for files (read and write for the owner; read for others).
 None
timeout

Time that the startCmd is allowed to run before being terminated. Use this attribute to catch a runaway process.

The time is counted from the moment the command specified in StartCmd is called.

 600 seconds
successCodes Return codes that indicate successful execution of the startCmd. Specify integers.

To specify a list of codes, separate with commas. For example, successCodes=”0,1”.

To specify a range of codes, separate with a colon. For example, to specify all codes from 0 to 10, enter successCodes=”0:10”.

If you specify success codes and the code returned is not among the specified successCodes, the system considers the install startCmd failed and deployment is aborted.

 Undefined. All return values indicate success.

uninstall section

Optional. Use the uninstall section to configure commands to run if the startCmd specified in the install section fails, or before the package is removed from a compute host.

uninstall > osType attributes

Attribute Description Default Value
name Required: Operating system type name.
Commonly used values:
  • X86_64: For a Linux-based 64-bit environment
  • LINUXPPC64LE: For Linux-based, 64-bit PowerPC Little Endian environment

For a complete list of valid values, refer to $EGO_CONFDIR/ego.shared.

None
startCmd Required: Command to run if the startCmd specified in the install section fails, or before the package is removed from a compute host.

For example, if your package contained a subdirectory called scripts with the command you want to invoke called myscript, specify:

./scripts/myscript

When removing a package from a compute host, if you specify the wrong execution user in the startcmd script, the system considers the uninstall startCmd to have failed, but the package is still removed. You must then manually clean up the working directory.

 None
timeout Time that the startCmd is allowed to run before being terminated. Use this attribute to catch a runaway process.

The time is counted from the moment the command specified in StartCmd is called.

 600 seconds
successCodes Codes, which when returned, indicate successful execution of the startCmd.

To specify a list of codes, separate with commas. For example, successCodes="0,1".

To specify a range of codes, separate with a colon. For example, to specify all codes from 0 to 10, enter successCodes="0:10".

If you specify success codes and the code returned is not among the specified successCodes, the system considers that the uninstall startCmd failed. However, the package is still removed.

 Undefined. All return values indicate success.

packageDependencies section

Optional. Use the packageDependencies section to define packages (such as class libraries) on which the service package depends.

package attribute

Attribute Description Default Value
name Required: Name of the package that the service package depends on. None