VMware Aria Automation: Nested OOTB Day 2 Actions with Resource Actions

VMware Aria Automation 8.12.0 Feature - Ability to Run Custom Actions and Out Of Box Day2 Actions in parallel.

Introduction

One powerful extensibility capability in VMware Aria Automation is the concept of custom resource actions. These actions provide a mechanism by which an administrator can expose additional functionality related to a given resource. Operations such as Power On, Shutdown, Create Snapshot, etc. are examples of some of the out of the box (OOTB) day 2 actions for virtual machine resources. Developers can create custom day 2 actions based on business logic and criteria with Automation Orchestrator workflows or VMware Aria Automation extensibility actions. Examples of custom day 2 operations may be something like updating a record in a CMDB, adding a machine to a backup policy, moving a machine from one Active Directory OU to another, etc.

It has been a common and popular practice to leverage custom resource actions in vRealize Automation 7 to 'override' OOTB day 2 actions by creating custom 'wrapper' actions. These wrappers were utilized to provide custom forms for OOTB day 2 actions. Perhaps the customer wanted to create a flow of business logic that involved invoking one or more serially executed OOTB actions on a resource. The answer was a custom resource action. For example, one custom action would first power off the machine, then perform some business logic based on the machine's custom properties, modify the machine's configuration in vCenter, and finally power the machine back on. All within a single flow of logic initiated by the context menu of a VM resource.

Like vRealize Automation 7.x, VMware Aria Automation, too has custom resource actions. However, the resource actions in VMware Aria Automation 8.x have had a limitation preventing users from creating custom actions that called OOTB day 2 actions. Hence, no overriding capability by leveraging a workflow wrapper. A custom resource action could not invoke an OOTB day 2 action as VMware Aria Automation would lock the resource from other operations whilst one was already in an executing state. Even OOTB day 2 actions were blocked when invoked from a custom resource action. Customers have had to work around this issue using a complicated set of asynchronous workflows to emulate a multi-step day 2. One of the drawbacks of this workaround was that it only allowed for a "fire and forget" design pattern. This meant that no failure from a 'wrapped' day 2 could be caught from the parent action making the request.

We are happy to announce that this has been addressed with the release of VMware Aria Automation 8.12. Per the release notes, VMware Aria Automation supports custom actions and out of box actions running on same resource or deployment.

In this post we'll show what this looks like in Aria 8.

Scenario

Two specific use cases will be presented in this post:

A custom "Add Disk" resource action. This action overrides the default OOTB "Add Disk" resource action. The OOTB action presents the end user with specifics related to the disk configuration that may be beyond what is necessary. It can possibly lead to confusion for the end user. The example here will demonstrate how to create a custom action with a simpler UI for adding a disk.
A business process related to the infrastructure management of a specific virtual machine resource. In this case, let's suppose that the customer uses vRA to customize VM templates in vCenter and save them as "gold images" for future release. The business logic of the custom action will perform a "Clone VM to Template" operation such that the vRA VM is the basis for a new vCenter VM Template.

Custom Add Disk

Customers may want to simplify or customize an OOTB day 2 action. Below is the OOTB day 2 action for "Add Disk:"
The OOTB form includes several fields that the customer does not want to expose to the end user.

SCSI Controller
Unit Number
Use VM Folder
Encrypted
Persistent
Constraint Tags

The wrapper custom action will make these decisions on behalf of the user based upon infrastructure automation business logic.

In this case a simplified form will be presented to the end user for the "Add Disk" action. The only options available to the end user will be:

Name
Size

Once the user clicks Submit, VMware Aria Automation will trigger the workflow that calls back with the OOTB "Add Disk" action using the REST API.

The VMware Aria Automation UI has been updated to show the actions being performed on a resource. We can see both the custom resource action and the OOTB "Add Disk" operations are being tracked in VMware Aria Automation.

Clone VM to Template

Cloning a VM to template is a custom process that will perform operations on the resource, make calls to vCenter, and finally clean up. There are multiple OOTB day 2 calls made during this workflow. This demonstrates a larger set of nested OOTB calls inside a single custom resource action.

The UI will show the nested actions in the request history. In the following example the Clone to Template action is still in progress. The API call for "Create Snapshot" has completed and now the nested API call for "Shutdown" is still in progress.

Design Consideration

Nested day 2 actions that call other custom day 2 actions are not supported. This prevents accidental non-terminating recursive calls that would wreak havoc on the system. It also simplifies the call stack for debugging and troubleshooting. Let's say we wanted to call my Custom Add Disk to the Clone to Template action. The instinctive approach may be to just add our other custom action into the code path of the workflow for Clone to Template. This is what that looks like:

The enhanced version of the Clone Day 2 now calls the Custom Add Disk. This operation will be refused by the server as a custom day 2 is already in progress (i.e., the currently running resource action workflow).

The solution to the enhanced version of Clone to Template is to leverage Automation Orchestrator's workflow modularity to call the core logic of Add Disk within a straight-line code path. Building your resource actions as wrappers around core business logic will help to scale day 2 solutions. One approach to build the enhanced day 2 in Automation Orchestrator may look like this:

And finally, the nested OOTB resource action calls made from the custom day 2 action will be recorded in the history as individual resource requests.

Limitations

The new functionality provides a great way to further customize the VMware Aria Automation platform via extensibility. Keep in mind that the previous limitations for custom day 2 actions still apply. Mainly:

Out of the box deployment actions cannot be called from a custom deployment action.
If a resource action is in progress, no deployment (parent) action can be requested. I.e., the parent of the resource is locked. This applies to both custom and out of the box actions.
If a resource action is in progress, no resource action can be requested on the same resource. I.e., the resource is locked. This applies to both custom and out of the box actions. The previous section shows one example of implementing this particular use case.

Additionally, the following restriction applies:

No out of the box day 2 actions may be requested from a custom action that results in the deletion of any deployment resource, including the deployment itself.
If a custom deployment action is in progress:
- No custom deployment action can be requested. This is the same as #1 above.
- No custom resource action can be requested for any child resource of the deployment.

The reason for the last restriction is that VMware Aria Automation owns the state of the entire deployment for out of the box lifecycle actions. It is not safe to allow a resource custom action to modify the parent (deployment) or any of its child resources. Doing so could lead to inconsistencies in the object graph of the deployment, rendering the deployment in an unknown/broken state.

The sample code demonstrating the functionality can be downloaded from https://github.com/brandonwsaxe/code_vmware_pve_vra_day2_package/releases/tag/v0.0.0.

This Blog has been authored by Brandon Saxe.