Recurring Jobs

Introduction

CloudBolt is able to run any job or action on a user-defined recurring schedule. This can be useful, for example, for scaling up a service or powering on servers every morning, and shutting them down every evening, or for scheduling a particular rule to check for a misconfiguration once an hour, while running other rules just once/day.

Managing Recurring Jobs

CloudBolt Admins can see the recurring jobs that CB ships out of the box:

  1. Click Admin.
  2. Click Recurring Jobs.
  3. Click one of the job names to see more details about it, including its execution history.

Creating Recurring Jobs (from an existing job)

To create a new recurring job from an existing job:

  1. Return to the Recurring Jobs list page.
  2. Click Add a Recurring Job.
  3. Select Add from Job.
  4. Enter the info, decide whether to enable it or not, and be sure to return to the recurring job page to ensure that it is running as expected.

Creating Recurring Jobs (from an existing action)

To create a new recurring job from an existing action:

  1. Return to the Recurring Jobs list page.
  2. Click Add a Recurring Job.
  3. Select Add from Action.
  4. Select an action type.
  5. Select Choose an existing shared CloudBolt plug-in or the equivalent button for other action types.
  6. Select an action from the list and click Create action for CloudBolt plug-in…. You will be returned to the Recurring Jobs list page, where the new Action will appear.
  7. Click the edit (pencil) button on the Action, or the Edit to Schedule link.
  8. Specify a schedule, in cron format, for the Action.
  9. If you chose a code-type Action that contains Action Input templates, enter default values for each Action Input.
  10. Click Save changes.

Creating Recurring Jobs (from a new action)

To create a new recurring job from a new action:

  1. Return to the Recurring Jobs list page.
  2. Click Add a Recurring Job.
  3. Select Add from Action.
  4. Select an action type.
  5. Select Add a new CloudBolt plug-in.
  6. Fill in the relevant details for the Action.
  7. Determine how to provide the code for the Action: by uploading a new one now, fetching one from a URL each time it runs, or by entering the code manually later. (If you choose the provide the code later, you will need to visit the Recurring Job’s details pages to edit the code.)
  8. Click the edit (pencil) button on the Action, or the Edit to Schedule link.
  9. Specify a schedule, in cron format, for the Action.
  10. If you chose a code-type Action that contains Action Input templates, enter default values for each Action Input.
  11. Click Save changes.

Out-of-the-box Recurring Jobs

CloudBolt ships with several Recurring Jobs out-of-the-box that you can use in your environment. Several support core functionality in the product, such as Resource Handler synchronization, so that you can customize their schedules or disable them entirely.

Auto-power control servers

Disabled by Default

This action enables powering off servers automatically for specified periods of the day. This can be useful for servers that do not need to run at night, to save on public cloud costs/resource consumption during those times of the day.

When the job runs, it looks for servers with a power schedule that includes being powered on or off for the current hour of the current day. Any such servers will be powered on or off, respectively.

To get started with this feature, Admin > Recurring Jobs > enable Auto-power control servers. Then either set a schedule for an existing server from its Power Schedule tab or provision a new server with a schedule using the Power Schedule parameter. (See the Servers page for more details.) Run the recurring job to test.

CloudBolt uses its own server time to judge whether it is the right time to power on and off VMs, so make sure you know what time it is on the CB server and that the timezone is right.

Also note that this recurring job is expected to be run every hour on the hour. If it is run on a different schedule, that will impact when servers are powered on or off. The power change will only happen if the job runs during the hour on the day when a power change is scheduled.

Sync all Resource Handlers

Enabled by Default

Pull a complete inventory to discover new VMs, update existing ones (including power status, hardware, name, etc), and mark ones that no longer exist as historical.

Run all CIT Tests

Enabled by Default

Run all enabled continuous infrastructure tests. See Admin > CIT for more info.

Execute all Rules

Enabled by Default

Execute the condition for all enabled rules to ensure compliance in the environment. See Admin > Rules for more info.

Update Search Index

Enabled by Default

Refreshes the search index that enables the global search feature. Running this on a regular basis ensures that objects new to CloudBolt will show up in search results.

The search index resides in /var/opt/cloudbolt/search_index/ and should only take a few minutes to update.

Refresh All Server Utilization

Disabled by Default

Execute any action whose name starts with “Refresh Utilization “. Updates server utilization stats used in reports. See sample action “Refresh Utilization for VMware Servers”.

Clean RH Networks & Templates

Disabled by Default

Clean up any networks or templates in CB that are no longer valid by syncing with what is on the Resource Handler.

Delete Old Job Records

Enabled by Default

Clean up any jobs in the CB database that are older than a specified threshold (365 days by default, or 30 days for sync VMs jobs). It is more aggressive with sync jobs since there are more of them than other jobs and they are also less important to keep for historical purposes.

This also deletes any log files for these jobs that are on this CloudBolt server, but does not delete any history events created by those jobs (ex. the history event on a VM showing when it was created).

This cleanup job runs once a week by default.

Caveats

Recurring jobs will each only have one running job at a time. Ie. if there is already an active job running for a particular recurring job, and it comes time to spawn a new job, CloudBolt will detect that one is already running, skip spawning a new one, and log this occurrence in the job engine log file (typically /var/log/cloudbolt/runjobs.log).