Orchestration actions

An orchestration action runs at a trigger point, one of the many predefined places in CMP processes where custom code can run. Trigger points are grouped into categories on the Admin > Orchestration Actions page. If a trigger point invokes an action that requires additional inputs, provide defaults for that action in this context. The same underlying action can have different defaults when invoked from different trigger points.

Find a trigger point

Go to Admin > Orchestration Actions. The tree on the left lists every category and, under each, its trigger points, each with a count of the actions currently attached. Select a category to see all of its actions, or select a single trigger point to narrow the table to that one. The table lists each action’s name, type, trigger point, and whether it is enabled. When you scope the table to a single trigger point, the Trigger Point column is hidden, because the tree already shows which one you are looking at.

(opens full-size image in a new tab)

Selecting a single trigger point also reveals an add button named after that trigger point, such as Add Post-Delete Action. A new orchestration action must be attached to a trigger point, which is why the button stays hidden until you pick one. When the table is scoped to one trigger point, you can drag its rows to set the order in which the actions run.

(opens full-size image in a new tab)

Trigger point categories

Continue on failure

An orchestration action can be set to continue on failure, which means that if the action fails, the rest of the job is unaffected. The job neither fails nor changes course. This is useful for actions that occasionally fail but whose failure does not prevent the job from completing successfully.

A few trigger points do not honor this setting, including the two trigger points in the Parameters category, as well as Generated Hostname Overwrite, Pre Server Refresh, and Compute Server Rate.

Job trigger points

Actions can be executed at many points throughout the job flow. For each job type, actions are executed in the order listed below, where <job-type> represents the job being run:

1. Pre-Job
2. Pre-<job-type>
3. The actual job runs, and can call out to additional trigger points specific to that job type, such as the trigger points in the Provision Server category
4. Post-<job-type>
5. Post-Job

Pre-Job and Post-Job are in the Other category rather than under a specific job type, because they apply to every job.

By default, post-job actions run regardless of the main job’s result, even if the main job fails. To run an action only when the job finished with particular statuses, edit the action at that trigger point and set the statuses it should run on.

Provisioning job trigger points

The Provision Server job has trigger points that occur during the job, not just before and after it. Under Provision Server in the tree, the trigger points are listed in the order they are executed during a provision job.

Order trigger points

The Order Related category covers validation, approval, and execution of orders. The trigger points used most often are:

• Order Submitted for Approval: Executes when an order is submitted for approval. Mainly used to integrate CMP with third-party change management systems.
• Post-Order Approval: Executes after an order is approved and before jobs are created. Used to alter job parameters before they are executed.
• Post-Order Execution: Executes when an order is marked as completed, whether it succeeded or failed.

The category also includes Generated Resource Name Overwrite, Blueprint Validation, Server Tier Validation, Post-Order Denied, and two notification trigger points: Order Submitted for Approval Notifications and Post-Order Execution Notification.

Form validation for blueprint orders without server tiers is handled at Blueprint Validation. For blueprints that require server-tier validation, use Server Tier Validation.

Order Submitted for Approval and Post-Order Approval are also used in custom order approval workflows. For more information about implementing your own approval workflow, see Special case plugins. To customize blueprint deployment specifically, see Blueprint actions.

Group and environment trigger points

The Group & Environment category contains six trigger points:

• Post Group Creation and Post Environment Creation are passed an argument called group and environment, respectively.
• Post Group Modification and Post Environment Modification are also passed an argument called group and environment, respectively.
• Pre Group Modification actions are passed arguments called group and existing_group. Compare the two in the action; if the action returns a FAILURE status or raises an exception, the object is not saved. These actions do not run when many-to-many relationships on the group change, such as its parameters, only when the group itself is saved.
• Pre Environment Modification actions are passed arguments called environment and existing_environment. Compare the two in the action; if the action returns a FAILURE status or raises an exception, the object is not saved. These actions do not run when many-to-many relationships on the environment change, such as its parameters, only when the environment itself is saved.

Here is a sample Pre Group Modification plugin:

"""
This plug-in, to be run at the "Pre Group Modification" trigger point, prevents
any modification to groups that add "cheese" to their description.
"""
from common.methods import set_progress

def run(job, group=None, existing_group=None, *args, **kwargs):
    if existing_group.description == group.description:
        set_progress("No change in group description.")
        return
    # These messages will show up in CB's application.log
    set_progress(f"Group's description was: {existing_group.description}")
    set_progress(f"Group's description will be: {group.description}")
    if "cheese" in group.description:
        return ("FAILURE",
                "Invalid group description",
                "'cheese is not allowed in the group description.'")

Parameter trigger points

The Parameters category contains two trigger points:

• Parameter Change: Executes whenever a user changes a parameter on a server. Use it to alter the server or contact another system when parameter values change.
• Generated Parameter Options: Dynamically determines which options are presented to a user for a parameter and can specify an initial value among those options. These actions contain a get_options_list method that returns either a list of option tuples or a dictionary containing both the options and the initial value. See Action input parameters, where the method has the same possible return values.

User trigger points

Two trigger points in the Other category relate to users:

• External Users Sync: Executes each time an external (AD or LDAP) user logs in. Use it to update a user’s permissions and group membership in CMP based on data held in the directory.
• SSO User Update: Executes when a user logs in through single sign-on. See SSO orchestration actions.

Terraform orchestration actions

The way Terraform commands are invoked is exposed as Terraform orchestration actions, allowing administrators to customize both how Terraform is invoked and how the resulting resources are integrated with CMP. The Terraform Related category is shown only when Terraform is in use. See Terraform operations.