Thanks to Matteo Brioschi for his support for this blog!
VCF Automation manages a full deployment cycle from the request of the process until disposal of the resource. In this context the object in question will be tracked as a deployment as long as it exists. Customers can use that deployment to invoke day-2 actions on its resources. Examples are reboots, power on/power off, console access for virtual machines or modifications of firewall rules for NSX network objects. While there are many day-2 actions delivered out-of-the-box, many customers develop their own actions through workflows based on business needs and include them in VCF Automation. Those are called “custom resource actions” and offer most flexibility on the platform.
By default, custom actions are visible for all objects of a specific type. However, there might be reasons to show a custom action only on specific objects which can be controlled by conditions. I will show in this blog how this can be achieved in a rather dynamic way using tags.
Visibility of day-2 actions
In my case I am using a “custom add disk” action which provides a simple way for consumers to add a disk with way less parameters needed compared to the default “add disk” action. I will not walk through the process of how a custom action is being created. There are multiple documentations around this topic available on the web.
Once a custom action is created, it is showing up in the action’s menu of the VM resource that has been deployed.
Let’s use an example to show this action only on VMs that are using the “CentOS8” template. This can be achieved by adding a condition in the resource definition.
Once that condition is in place, the action will only show up on the objects that meet the condition. Any of the object’s properties can be used to manage visibility. A list of available properties is shown when opening the object schema under the Resource Type in the custom action definition:
Visibility based on tags
The default capabilities only allow usage of the out-of-the-box properties of an object for the custom action condition statements. In many scenarios, however, more dynamic values shall be used like custom properties. This would mean that visibility can be controlled by input values the consumer provides during the request. As an example, a user might have selected an additional service level which causes higher charge but allows for more capabilities like adding an additional disk. This can be a selection option during the request which then sets a specific “property”. As an example this might be implemented by a dropdown where the user selects the service level “basic” (which does not set the property) or “advanced” (which does set the property).
One challenge that comes up is that the visibility condition for the custom action does not honor custom properties. To find another way of implementation, tags can be used.
This means that in the cloud template definition, a tag is added to the VM part:
The value of the tag obviously can be defined by a user input as well. In this example we are just hard-coding it.
On the custom action side, it requires to use the advanced editor for conditions:
You can use this example code and modify it to your purpose:
matchExpression:
- and:
- key: ${properties.tags}
operator: hasAny
value:
matchExpression:
- and:
- key: key
operator: eq
value: diskday2
- key: value
operator: eq
value: 'yes'
You might notice an error message with a red exclamation mark. This has no effect and can be ignored. Once the custom action is saved, it will not appear again.
Testing the scenario
After the implementation just verify if the day-2 action is available on a deployed VM or not – depending on if the tag has been set as desired or not.
Have fun!
- VCF Automation – Custom Day-2 action visibility based on tags - 18. March 2025
- Capacity Management for vSAN Storage Policies - 20. December 2024
- Extend vCenter metrics with Management Pack Builder - 20. December 2024