Actions on CloudBolt Documentation

Action context

Mon, 01 Jan 0001 00:00:00 +0000

Actions are one of the most powerful ways to extend CMP. Besides the action inputs you define, several CMP objects are available as context to any template-enabled action attribute, such as plugin source, a webhook payload, or an email hook body. To see which attributes can be templated for each type, see Action types.

This context is also available outside actions, when custom YAML files provision Kubernetes objects. See Container orchestrators.

Built-in context by use case

Single server action

Run by a user on an existing server.

Action types

Mon, 01 Jan 0001 00:00:00 +0000

The six action types

CloudBolt Plugin: Runs a Python module on the Cloud Management Platform (CMP) server, with access to internal APIs.
Remote Script: Runs a script on the target servers rather than on the CMP server.
Copy File: Copies a file to the target servers. This type is marked Beta in the user interface.
Webhook: Makes a call into an external, web-based API.
Email Hook: Sends an email.
External Flow: Runs a flow held in an external orchestrator.

Not every type is available everywhere

The types available when you create an action depend on where you create it. CloudBolt Plugin is always available. The others are offered conditionally:

Action input parameters

Mon, 01 Jan 0001 00:00:00 +0000

CMP scans the actions you define to determine whether the action needs additional input in order to run. This process is covered in more detail in the documentation for each action type. CMP then prompts users for those inputs, or substitutes pre-designated default values where appropriate.

CMP does not create action inputs for template variables that start with the keyword server, such as {{ server.ip }}. For the full list of context keys, see Action context.

Action retries

Mon, 01 Jan 0001 00:00:00 +0000

Every base action has a max retries value: the maximum number of times to retry the action if it fails. Whenever the action runs and returns an unsuccessful status or raises an exception, Cloud Management Platform (CMP) retries it up to that number of times. This is useful for actions that interact with a flaky external system.

(opens full-size image in a new tab)

Export and import actions

Mon, 01 Jan 0001 00:00:00 +0000

Actions can be exported as files so they can be reused across Cloud Management Platform (CMP) instances or shared in the CloudBolt Forge, a repository of sample CMP resources. An exported action is a zip file containing JSON-formatted metadata about the action, along with any scripts it uses.

Exporting

When exporting, choose between a sanitized and an instance-specific version of the action. The formats are the same, but the sanitized version omits potentially sensitive information such as script credentials, environments, and groups. Sanitized versions are suitable for sharing on the CloudBolt Forge or for moving actions between instances that do not have the same groups and environments.

File copy actions

Mon, 01 Jan 0001 00:00:00 +0000

A file copy action sends a text or binary file to the servers in context, which is useful for both servers being provisioned and existing ones. File copy actions can be used in blueprints, as server actions, and as orchestration actions. The action type appears as Copy File and is marked as Beta in the user interface.

File copy action fields

In addition to the fields common to all actions, a file copy action has the following:

Resource actions

Mon, 01 Jan 0001 00:00:00 +0000

A resource action puts a button on the detail page of a deployed resource. When a user selects it, it runs an action of any of the six action types. Administrators create them in Cloud Management Platform (CMP) at Admin > Resource Actions.

What resource actions can do

A resource action can run scripts on all or a subset of the server tiers in the resource, call an integration, email users, or run code that reads and writes information to and from the resource via the CMP database. Browse the Content Library or the CloudBolt Forge to see examples.

Server actions

Mon, 01 Jan 0001 00:00:00 +0000

A server action appears as a button on a server’s detail view and runs an action of any of the six action types. When a user runs one, Cloud Management Platform (CMP) prompts for any inputs the action needs and then creates a job to run it asynchronously. The job also serves as the audit trail of who ran what, against which server, and when. The equivalent for deployed resources is a resource action.

Scheduling actions

Mon, 01 Jan 0001 00:00:00 +0000

Scheduling is off by default. Enable it on the action, and users then get a choice of running now or later each time they launch it.

Enable scheduling

Go to Admin > Server Actions or Admin > Resource Actions.

(opens full-size image in a new tab)
Select an action.
Select the Edit button.
Clear Synchronous Action if selected, and select Allow scheduling. Synchronous actions run inline and cannot be deferred.

(opens full-size image in a new tab)
Select Save.

Email hooks

Mon, 01 Jan 0001 00:00:00 +0000

An email hook is an action type, so it can be attached anywhere other actions can. Its subject and body are templates, which lets a single hook produce a message tailored to the job that fired it.

Email hook fields

In addition to the fields common to all actions, such as name and description, an email hook has the following. None of them are required.

Field	Description
Subject	The subject line of the email.
Body	The body of the email.
From Address	The address the email is sent from. If it is empty, CMP uses Email default from address from Admin > Email Settings.
Send to Users	Choose from all users in your instance, including those imported from LDAP. The email goes to the address shown on each user’s detail page.
Send to Address	A comma-separated list of recipient addresses. It accepts templated addresses, such as `{{ server.owner.user.email }}`.
Send to Job Owner	When selected, the email goes to the owner of the job the hook is attached to. The job details page shows each job’s owner.

The Subject, From Address, and Body fields can all be templated using parameter templates.

Outbound webhooks

Mon, 01 Jan 0001 00:00:00 +0000

An outbound webhook is an action of the Webhook type. It integrates CMP with external systems that expose a web-based API, typically REST. Use one to post a message to a channel whenever a particular blueprint is deployed, create an entry in a CMDB when a new server is built, or enable and disable monitoring when a user selects a button on the server details page.

To let an external system call CMP instead, see Inbound webhooks.

Inbound webhooks

Mon, 01 Jan 0001 00:00:00 +0000

An inbound webhook adds a URL to the CMP API that runs a plugin you write. It also offers a simpler authentication option, which makes CMP easier to call from external systems.

To have CMP call an external API instead, see Outbound webhooks.

Why use inbound webhooks

You may want another system to call into the CMP API to fetch information or perform an action: a chatbot that reports how many VMs and public cloud accounts CMP manages, for example, or one that kicks off provisioning of a development environment when someone asks for it.

External flows

Mon, 01 Jan 0001 00:00:00 +0000

An external flow is an action type that invokes an external orchestrator. Once a flow is mapped to an action, it can be used anywhere an action can be used: at an orchestration trigger point, as part of a blueprint deployment, or from a server’s details page.

Set up an external flow

Configure an external orchestrator and import one or more of its flows.
Create actions in CMP that map to those flows.

The External Flow action type is offered only when the external orchestrators feature is active and at least one orchestration engine is configured. If you do not see it when creating an action, check both.