CloudBolt supports expiring both servers and services, and configuring what happens to each upon expiration. In both cases, the server or service is marked for expiration using the Expiration Date parameter.
Expiration of Servers¶
To indicate that a server should be expired on a particular date, it must have a value for the Expiration Date parameter. This value can be provided at provision time as described in the Order Form Customization section, or added to a previously-provisioned server using its Parameters tab.
Checks for expired servers are done using a shell script called expirescan.sh, which is run nightly using crontab by default. Administrators of the CB server can run an expire scan manually or change the crontab entry to a different schedule.
The behavior that should occur on expired servers is defined using the Pre-Expire Server and Post-Expire Server trigger points on the Expire tab of the Orchestration Actions page. You can make use of the given example actions, adapt them as desired, or develop your own, and also enable and disable as appropriate, in order to obtain the behavior your organization is looking for with expiring servers.
Expiration of Services¶
To tell CloudBolt that a deployed service should be expired on a particular date, give it a value for the Expiration Date parameter. This parameter can be provided at order time using Blueprint-level Parameters, or added to an existing service using its Parameters tab.
Checking for expired services is done with a rule that comes with CloudBolt out-of-the-box, but is disabled by default. If enabled, the rule will run on a schedule with the other rules based on a crontab entry. It can also be run manually. See the Rules section for more information.
The condition portion of the rule contains the logic for determining which services have expired, but does not actually do anything with them. You can edit as necessary, but most of the logic you’re interested in will likely live in the then action(s).
Configuring what should happen with expired services is done using the then action(s) of the Expire Services rule. An example has been provided that sends warning emails to service owners and potentially deletes services that have been expired for more than a threshold number of days (defaults to 30). You can make use of that example, adapt it as necessary, or develop your own action(s), and also enable and disable as appropriate, in order to obtain the behavior your organization is looking for with expiring services.