Errands

Lifecycle errands are BOSH errands (scripts) that run at the beginning and end of an installed product’s availability time. Product teams create errands as part of a product package, and a product can only run errands it includes. For more information about BOSH errands, see BOSH documentation, and for more information about errands in Pivotal Cloud Foundry (PCF), see Managing Errands in Ops Manager.

Products can have two kinds of errands. Post-deploy errands run after a product installs but before Ops Manager displays makes it available for use. Pre-delete errands run after an operator chooses to delete a product, but before Ops Manager finishes removing it from use.

To save deployment time, operators can set errand run rules that dictate whether or not errands run. Tile authors can set defaults for these run rules.

WARNING: As of Ops Manager v10.0.0, errands set to the When Changed rule do not always run when the tile has relevant changes. Instead of using When Changed, Pivotal recommends that tile developers leave the default run rule for errands as On and let operators use one-time rules to turn errands off and save deploy time.

Post-Deploy Errands

Post-deploy errands run after a product installs, but before Ops Manager makes it available for use.

Typical post-install errands include smoke or acceptance tests, database initialization or database migration, and service broker registration.

Post-deploy errands run by default. An operator can prevent a post-deploy errand from running by setting its run rule to Off under Pending Changes in the Ops Manager Installation Dashboard or on the product tile’s Settings tab Errands pane, before installing the product.

Example Errand

For example, Redis has a Broker Registrar post-deploy errand that the Elastic Runtime tile uses to register its service broker with the Cloud Controller and publish its service plans.

If an operator chooses Off in the drop-down menu for Elastic Runtime’s Broker Registrar errand before installation, Elastic Runtime’s service broker is not registered with the Cloud Controller and its service plans are not made public.

Pre-Delete Errands

Pre-delete errands run after an operator chooses to delete a product, but before Ops Manager actually finishes deleting it.

Typical pre-delete errands include clean up of application artifacts and service broker de-registration. For example, Pivotal MySQL has a Broker Deregistrar pre-delete errand that:

  • Purges the service offering
  • Purges all service instances
  • Purges all application bindings
  • Deletes the service broker from the Cloud Controller

When an operator chooses to delete the Pivotal MySQL product, Ops Manager first runs the Broker Deregistrar pre-delete errand, then deletes the product.

Pre-delete errands run by default. An operator can prevent a pre-delete errand from running by setting its run rule to Off under Pending Changes in the Ops Manager Installation Dashboard or on the product tile’s Settings tab Errands pane, before installing the product.

Errand Run Rules

Some errands do not always need to run. For example, installing a minor patch to a existing service might not require re-registering its broker. Ops Manager lets operators save installation time by turning errands off or on. They set these errand run rules in two places:

  • One-Time Rules under Pending Changes in the Ops Manager Installation Dashboard. These rules only apply to the next time you run Apply Changes and do not persist after the next successful installation.
    Pending Changes

  • Persistent Rules in the tile’s Errands pane. These rules persist through subsequent installations, until changed in the Errands pane.

For more information, see Configure Run Rules in Ops Manager.

Create a pull request or raise an issue on the source for this page in GitHub