Managing service package dependencies

Some service packages depend on common libraries that may require periodic updates. For these service packages, it is possible to separate common libraries into individual packages and maintain the dependencies so that the service package only includes the main binaries.

With this feature, a complex package can be organized into multiple smaller packages, which can be more easily maintained. It also saves disk space in the RS server as well as reducing the SIM download time if several packages share common libraries. A package that has a dependency can only depend on packages that are deployed at the same consumer or its ancestor consumers. The packages that a main service binary depends on are known as dependent packages. In a typical case, the dependent package libraries are deployed under root consumer "/". Packages deployed with short names can only depend on packages deployed under the same consumer or root consumer. Packages cannot have mutual dependencies among them, e.g., both package A and package B are deployed under the same consumer; A depends on B, and B depends on A.

Package upload

A package can be uploaded/updated individually even if it has dependency on other packages or other packages have dependency on it. The RS performs a dependency check when a package is uploaded and gives a warning if the dependent packages are not deployed yet. It is recommended to upload the dependent pacakges first to avoid such warnings.

Package removal

When removing packages with dependencies, it is recommended to remove the packages that have no other packages depending on them first, then remove the dependent packages. Otherwise, the dependency check fails and the RS rejects the remove request.

Package dependency and dynamic application updates

If any package of an application changes, whether it is the package the application directly uses or the packages it indirectly depends on, a dynamic application update is triggered. Following the change, the updated package will be downloaded by the SIM in the compute host.

Package dependency and application profiles

Only the package that is directly used by an application is configured in the application profile. The dependent packages do not appear in the application profile and are only maintained by the RS. This way, the application profile is not affected by any dependency changes.

Internally, the SD sends an application profile to the SSM that includes package version as well as all dependent packages. The SIM downloads the packages and all its dependencies by reading the application profile sent from the SSM. The SIM cannot start a task unless all packages have been successfully downloaded and are current.

Package environment variables

You can define environment variables for each package that are propagated to the service instance. The definition can use any previously defined environment variable and "SOAM_DEPLOY_DIR". Here "previously defined variables" includes variables defined in package dependencies. Example:

JAVA_HOME=${SOAM_DEPLOY_DIR}

PATH=${JAVA_HOME}/bin:${PATH}

On Windows, ${SOAM_DEPLOY_DIR} of each dependent package is added to the PATH environment variable for the service. On Linux/UNIX, ${SOAM_DEPLOY_DIR} of each dependent package is added to the PATH and LD_LIBRARY_PATH environment variables for the service.

Here is the order of precedence for environment variables used by services:

  • If the environment variable defined in the package or any package dependencies already exists in the system, it will overwrite the one in the system.

  • If a dependent package defines an environment variable that is the same as the one defined in this package, the one defined in this package overwrites the environment variable in the package dependency.

  • If two dependent packages define the same environment variable, the package listed later in the deployment.xml overwrites the former.

  • If the same environment variable is defined in one package more than once, the one defined later is ignored.