CloudCenter 4.8 has reached End of Life (EOL) as of November 14, 2018. See End of Support Notices for additional context.

Agent (Service) Lifecycle Actions


A service goes through various phases as it becomes operational. Agent (Service) Lifecycle Actions allow enterprises to define a script or command that must be executed during different service lifecycle phases.

The root or tenant administrator can import and add services that are specific to their enterprise using the Services > Add Service function. 

See Define a Custom Service for additional context.

Lifecycle Actions

Users can define scripts for each of the following phases for each service when they add/edit a service.

UI Service ActionAPI EnumerationDescription



The install service phase is implemented when the node first comes up.

Similar to the image installation process, the CloudCenter platform also abstracts all supported out-of-box Services into small, individual files made available through The CloudCenter Worker1 image. When you drag and drop a service (any supported or customer-defined service) from the Topology Modeler Services tab into the Topology Modeler graphical interface, you are instructing the CloudCenter platform to use this service to model or deploy your application. At this point, all service files (ZIP format), regardless of each being a CloudCenter-supported or customer-defined service, are automatically extracted (from their respective locations — either Package Store ( or you own Artifact Repository to the /usr/local/osmosix/ directory. The ZIP file for each service contains the root folder. For example, when you use the Tomcat7 service, the extracted file contains a root folder called Tomcat7. This /usr/local/osmosix/Tomcat7 folder contains the scripts related to this service. Use this perspective accurately when you call additional scripts and parameters (see Parameters and Macros) in the Topology Modeler Properties tab.

The install phase does not have any environment variables.


Once all nodes are initialized and started, you must specify this action for services that need these files deployed into a particular service at the time of deployment.


Modify a configuration based on a requirement – If an application like NginX requires all the IP addresses for each application tier, you can configure this service to perform the related actions.


A service start action only occurs when all the nodes in the deployment are up and running.

Some enterprises may have a script specifically for starting the services. If you have the file in the /usr/local/osmosix/service directory, this file executes each time the service starts.

When you reboot a service, the IP address may change. This action may need you to reconfigure all connected IP addresses. So you need to call the Configure action and the Start action to complete the lifecycle process.


When shutting down the node, you can perform related cleanup actions.


When you restart the system from the UI after shutting it down, you can specify what actions need to be performed.


The IP address changes for connected nodes. For example, if any connect node restarts for any reason in a three-tier deployment, you can configure a reload command to internally reload the affected services.


When upgrading the deployment, you can identify the dependent factors for each service.

Clean Up


When a node is being terminated, you can specify the related clean up command, script, or URL.

Other References

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved