CloudBolt supports expiring both servers and resources, and configuring what happens to each upon expiration. In both cases, the server or resource 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 Resources¶
To tell CloudBolt that a deployed resource 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 resource using its Parameters tab.
Checking for expired resources 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 resources 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 resources is done using the then action(s) of the Expire Resources rule. An example has been provided that sends warning emails to resource owners and potentially deletes resources 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 resources.