Aria Automation

vRA Action Placement Demystified

The new extensibility framework in vRealize Automation (vRA) called Action Based Extensibility (ABX) provides the ability to leverage FaaS (Function-as-a-Service) to write simple scripts in various programming languages (e.g. Python, Node.js) to fulfill both simple and complex extensibility use cases. It is available in vRA 8.0 (on-prem) and in vRA Cloud.

An Action can be generic, a regular script not semantically tied to a specific provider, and the ABX framework can deploy and execute it transparently on both the public and private cloud. Currently, there is support for three FaaS providers:

  • On-Prem
    • Using the Extensibility Cloud Proxy for vRA Cloud
    • With the built in FaaS engine in vRA
  • AWS Lambda
  • Azure Functions

Which provider will be picked for action execution as part of virtual machine provisioning depends on how the framework is configured through the following three configuration steps.

The FaaS provider configured in the action itself, which will be automatically picked by the underlying algorithm when Auto is selected.

The cloud zones configured in the project where the action is created.

For vRA Cloud only, the extensibility constraints are in the project.

FaaS Provider Configured as part of the Action

ABX supports four distinct values, three of them corresponding to the desired specific provider (i.e. AWS, Azure or on-prem) and Auto. A provider should be selected if the code of the action calls specific APIs of AWS, Azure or vSphere, i.e. in case it is provider specific. Typically, the default value of Auto should be left selected, as most of the time the code of the action will be generic, and the underlying placement algorithm will select the most appropriate provider based on the cloud zones in the project and the provisioned resource.

If the code has to interact with on -rem systems and APIs, it’s natural to make the action always run on the on-prem provider, as code executed in the public cloud typically will not be able to reach these systems and APIs.

Cloud Zones in the Project

If the value in the action is Auto, which is the default, then the placement logic will look into the cloud zones available in the project in which the action is created. It will take into account the priority and the extensibility constraints. Typically the zone with the highest priority within the project will be selected for executing the action, where a lower number means higher priority.

Extensibility Constraints (for vRA Cloud only)

As there might be multiple Extensibility Cloud Proxies deployed in a vRA Cloud organization, for on-prem execution of actions the appropriate proxy is selected based on the configured extensibility constraint tag in the project, which must match a capability tag on an ABX On-prem integration. For on-prem vRA this is not necessary as there is only one build in on-prem action execution engine and it’s matched by default by the placement algorithm.

Example with vRA 8 – Testing an Action

The ABX on-prem provider comes out of the box with the vRA 8 installation.

We create a very simple python action with Auto pre-selected in the FaaS provider field. Note that actions are created in projects, so at least one project must already exist in the system before attempting to create the action.

handler(context, inputs):
    greeting = "Hello, {0}!".format(inputs["target"])
    print(greeting)

    outputs = {
      "greeting": greeting
    }

    return outputs

Saving the action and clicking on the Test button triggers the action and if we observe the trace, we will see that the on-prem provider was selected by the algorithm.

Unless AWS or Azure cloud zones have been added to the project with an appropriate priority or tags, on-prem is selected by default in vRA 8.

Example with vRA Cloud – Executing an action as part of VM provisioning

For this example, we have a Cloud Extensibility Proxy already deployed in our private data center and an ABX on-prem integration tagged with the following capability tag.

We also have a project with three prioritized cloud zones, one for each supported provider.

We have a very simple python action with Auto pre-selected in the FaaS provider field. The code is exactly the same as in the example above.

handler(context, inputs):
    greeting = "Hello, {0}!".format(inputs["target"])
    print(greeting)

    outputs = {
      "greeting": greeting
    }

    return outputs

We create a subscription for the Compute Provision topic and select our action as the runable item.

We define a simple blueprint with a single virtual machine, and make sure that it always gets deployed on vSphere by setting the platform:vsphere constraint which matches our vSphere cloud zone in the project.

inputs: {}
resources:
  Cloud_Machine_1:
    type: Cloud.Machine
    properties:
      image: ubuntu
      flavor: small
      constraints:
        - tag: 'platform:vsphere'

Once the blueprint is deployed, our action is triggered and the placement logic checks the zone in which the machine is being provisioned, which in this case is vSphere. Since the provider value in the action is Auto and the VM is vSphere, the algorithm decides that the action must be executed on-prem. It checks the extensibility constraints in the project and finds a match with a Cloud Extensibility Proxy, on which it subsequently executes the action.

The trace log of the action run shows exactly which provider was selected.

If, for example, the provisioning placement algorithm chooses to deploy the VM on AWS, then the ABX action placement logic would have selected the AWS cloud zone in the project and would have executed the action on AWS.

To override this logic, set the ignore.vm.endpoint custom property to true in the request. If this is done, the action placement algorithm will ignore the selected cloud zone for the virtual machine and will take into account all cloud zones in the project according to their priority.

When an action is run with the Test button or through the API, there is obviously no real virtual machine provisioning, so all the zones in the project are taken into account when selecting the provider.

Useful Tips

  • In most cases, the Auto setting in actions allows for the most flexibility, as provider selection will be based on the cloud zones of the project. If the setup of cloud zones changes, it will not be necessary to modify the configuration of the action.
  • When testing an action during the implementation, it makes sense to select a specific provider, as typically the action should be tested on all providers sequentially in a predictable manner. This ensures that the code is generic and can run on all supported platforms, which is usually the best practice.
  • The action run Trace is helpful for determining how the provider for the action run was selected.
  • Using the public cloud FaaS providers leads to small additional cost for the organisation, as services like AWS Lambda or Azure Functions are being utilised for executing the code. Typically, running actions on-prem does not incur any additional cost.

Further Resources

Related Posts:

Related Articles