Cloud Assembly – Extensibility with ABX (FaaS) – Part2

This is the second article in my mini series covering Cloud Assembly extensibility via ABX (Action Based Extensibility). Links to the other articles in the series are listed below:

In this article I am going to lay out an example extensibility scenario and start planning out a solution that will use ABX.

Our Scenario for ABX

The example scenario I am going to use is applying tags in vCenter when an on-premise workload is deployed. The idea is that as part of the provisioning process a user selects some information that ultimately will be used to tag the resulting workloads in vCenter.

I covered a similar scenario for applying Cloud Assembly Tags using vRO ( so this should be an interesting comparison. Lets look out how this should work.


First of all I need to decide at what stage during the deployment provisioning do I want my extensibility to run. As the use case is to apply a tag to something in vCenter it makes sense that this should be done after a workload has been deployed. If I were to try and do this before a workload had finished being created then I would likely get some sort of error back from vCenter.

There are many event topics to choose from. This flow gives you an idea of the events that are triggered through a typical on-premise deployment.

Cloud Assembly Event Flow

The “Compute Post Provision” event seems ideal as it will be fired each time a workload in the deployment reaches a fully provisioned state meaning that everything should be available in vCenter. The payload for this event also contains all the necessary information needed (i.e. machine name) where as the deployment level events do not.

Interacting with vCenter

This scenario deals with on-premise workloads and therefore using an on-premise implementation of OpenFaaS (i.e. the VMware Extensibility Appliance) allows the ABX actions that I will create to access vCenter without having to put in place (or open up) any additional connectivity between vCenter and public cloud solutions.

vCenter has a REST API that I will be leveraging for this use case so before I dive into code it’s a good idea to plan out what type of calls are going to be required and in what order.

The vCenter REST API has a great API explorer that you can hit with a web browser and run interactive calls with to try things out. You can access this by going to https://your_vc_fqdn/apiexplorer.

Here’s the calls available for API using API sessions.

Using the ApiExplorer I have pieced together the following:

  • API calls use a VMware session ID as an authentication token so the first thing is to obtain one. Without this I cannot perform any operations on objects within the vCenter inventory.
  • To tag a Virtual Machine we must first identify it. Although I will have the names of the machines from the Cloud Assembly event payload the REST API works using Virtual Machine Identifiers. The next call will therefore be to get the identifiers.
  • The name of the tag I want to apply to a virtual machine will be in the event payload however as per the previous item, tags are associated using their ID’s rather than names.
  • To locate a tags ID the API requires that all tags be fetched and then each one fetched via ID to verify a name match (also optionally category match). This is not an efficient method but the API calls are limited here.
  • The last part is to put together an API call to associate the tag identifier from step 4 with the VM identifier from step 2.

In the next article I will put all of this together to implement the use case with ABX.

2 thoughts on “Cloud Assembly – Extensibility with ABX (FaaS) – Part2

  1. Pingback: Cloud Assembly – Extensibility with ABX (FaaS) – Part1 | vnuggets

  2. Pingback: Cloud Assembly – Extensibility with ABX (FaaS) – Part3 | vnuggets

Comments are closed.