Aria Automation Custom Resource Types - Update Custom Properties
How to update custom properties in deployments of a custom resource type
Table of Contents
Deployment resources
Aria Automation deployment resources can be assigned custom properties. These properties can have an impact on how the resource created (name, size, ...), but can also store arbitrary metadata we want to use later for automation purposes (for example backup policy name).
Sometimes we need to change these values during the lifetime of the resource. For virtual machines the IaaS API provides a convinient way to do that via PATCHing /iaas/api/machines/{id}: we can specify the custom properties and values. The same API is exposed via Orchestrator Plug-in for vRealize Automation, one can use com.vmware.library.vra.infrastructure.machine/createMachineCustomProperties action to update the VM's custom properties.
There is no such interface for deployment resources in general, and for custom resource types in particular either. This article discusses the challenges and a solution to update custom properties of deployment resources with custom resource type.
Recap of the previous posts
In the previous posts Aria Automation Custom Resource Types - The Easy Way and Aria Automation Custom Resource Types - Schema update we created, and updated a custom resource type definition. In the third part Aria Automation Custom Resource Types - Onboarding we discussed how to get an existing resource under management.
Virtual Machine folder as a Custom Resource Type
In this fourth part we well use VC:VmFolder Orchestrator type implemented by the vSphere vCenter Plug-in. Previously we used a Dynamic Type, but we can use any existing vRO inventory object type (provided by plugins) as well as CRT. It does not matter for the current discussion as both work the same way.
Create VM folder workflow
The inputs of create workflow are: name of folder and owner (for demonstration purposes). The type of output is a VC:VmFolder.
To create a folder, we need a parent folder. For the sake of simplicity we will use a slightly modified version of com.vmware.library.vc.folder/getRootVmFolder code, not to fail in case of multiple Datacenters found, always selecting the first one:
1var vimHosts = VcPlugin.getVimHosts();
2var rootFolder = vimHosts[0].rootFolder;
3var datacenters = getAllDatacenters(rootFolder);
4System.log("Datacenter: " + datacenters[0].name);
5rootVMfolder = datacenters[0].vmFolder;
6
7function getAllDatacenters(folder) {
8...
After calling the Library/vCenter/Folder management/VM folder/Create virtual machine folder to create the folder within the root folder, we set the owner Custom Attribute. For that to work, we need to create a new custom attribute in vCenter to store our value:
The code to store the value, with returning the workflow output object:
1newFolder.setCustomValue("owner", owner);
2folder = newFolder;
Update VM folder, Delete VM folder workflows
The update workflow must have an input and output of type VC:VmFolder. We also add the name of folder to allow folder renaming.
This workflow is just a wrapper: first we call Library/vCenter/Folder management/VM folder/Rename virtual machine folder workflow, and return the VC:VmFolder object.
The delete workflow calls Library/vCenter/Folder management/VM folder/Delete virtual machine folder workflow.
With all 3 workflows implemented, we can start defining the CRT.
Define VMfolder Custom Resource Type
Refresh the workflow inventory in Cloud Assembly (Start Data Collection):
Define the CRT:
The schema is automatically created:
The input properties name and owner added from the create workflow inputs, and the output properties sdkId, name and id added from the plugin object type definition of VC:VmFolder. This works the same as Dynamic Types.
With that completed, we have a simple CRT to test with.
Cloud Template
We define three inputs for the template: name of the folder, owner and a comment. Each input is mapped as a property of the resource.
1formatVersion: 1
2inputs:
3 name:
4 type: string
5 owner:
6 type: string
7 comment:
8 type: string
9resources:
10 Custom_vmfolder:
11 type: Custom.vmfolder
12 preventDelete: true
13 properties:
14 name: ${input.name}
15 owner: ${input.owner}
16 comment: ${input.comment}The properties name and owner are directly used by the create workflow inputs, the comment property will be a custom property assigned to the resource. The preventDelete resource flag prevents folder deletion in case of resource request (update) performed on the object.
This is the new input form when deploying:
The created resource:
Note that the name and owner properties are visible on the GUI, but the comment is not. However, we can get it via API:
1$ curl -sSk -H "Authorization: Bearer $token" 'https://vra8.corp.local/deployment/api/resources?resourceTypes=Custom.vmfolder'|jq .
2{
3 "content": [
4 {
5 "id": "c6b68e9f-bc00-4371-962a-0dfbeefde4c5",
6 "name": "folder1",
7 "type": "Custom.vmfolder",
8 "properties": {
9 "owner": "kuklis",
10 "folder": {
11 "id": "group-v51870",
12 "name": "folder1",
13 "type": "VmFolder",
14 "@type": "VmFolder",
15 "sdkId": "vc.corp.local/group-v51870",
16 "dunesId": "vc.corp.local,id:group-v51870",
17 "@fullType": "VC:VmFolder"
18 },
19 "name": "folder1",
20 "resourceName": "folder1",
21 "comment": "comment1",
22 "id": "a8caa348-7980-4da9-b4ee-c8f9647b619c"
23 },
24 "createdAt": "2024-07-03T18:28:02.245705Z",
25 "syncStatus": "SUCCESS",
26 "origin": "DEPLOYED",
27 "deploymentId": "6341b47c-0f1d-4330-82ac-1eecfa0f8d87",
28 "projectId": "ffab9ffd-a072-4617-bbb4-54101b3b5dd1",
29 "orgId": "360bc331-1360-4d76-8000-aae9f7491989",
30 "billable": false
31 }
32 ],
33...The resulting VM folder on vCenter:
Updating properties
Custom properties are directly mapped to deployment inputs. We can change them by updating (changing) the inputs.
The updated deployment resource has updated custom properties (top) and resource properties (bottom):
The VM folder is renamed:
Updating custom properties
Let's try to update a custom property, the comment field:
We see that Aria Automation detects the resource does not need to be updated, as the input has no effect on the object (not mapped to an input):
If we submit the update request, and check the comment custom property, we see no change:
1curl -sSk -H "Authorization: Bearer $token" 'https://vra8.corp.local/deployment/api/resources?resourceTypes=Custom.vmfolder'|jq .
2{
3 "content": [
4 {
5 "id": "c6b68e9f-bc00-4371-962a-0dfbeefde4c5",
6 "name": "folder2",
7 "type": "Custom.vmfolder",
8 "properties": {
9 "owner": "kuklis",
10 "folder": {
11 "id": "group-v51870",
12 "name": "folder2",
13 "type": "VmFolder",
14 "@type": "VmFolder",
15 "sdkId": "vc.corp.local/group-v51870",
16 "dunesId": "vc.corp.local,id:group-v51870",
17 "@fullType": "VC:VmFolder"
18 },
19 "folder_in": {
20 "id": "vc2.poc.local,id:group-v51870",
21 "type": "VC:VmFolder"
22 },
23 "name": "folder2",
24 "resourceName": "folder2",
25 "comment": "comment1",
26 "id": "a8caa348-7980-4da9-b4ee-c8f9647b619c"
27 },
28 "createdAt": "2024-07-03T18:28:02.245705Z",
29 "syncStatus": "SUCCESS",
30 "origin": "DEPLOYED",
31 "deploymentId": "6341b47c-0f1d-4330-82ac-1eecfa0f8d87",
32 "projectId": "ffab9ffd-a072-4617-bbb4-54101b3b5dd1",
33 "orgId": "360bc331-1360-4d76-8000-aae9f7491989",
34 "billable": false
35 }
36 ],
37...In order to update a resource property, we need to add the property as an input to the create and update workflows to trigger a deployment resource update.
Introducting a fake input
This will have no direct affect on the VM folder creation or update process, but will trick the automation engine to run the update workflow and update the custom property a the same time.
We need to refresh the workflow inventory in Cloud Assembly (Start Data Collection) again, and update the custom resource type schema:
Updating the custom property with the fake input
Let's try to update the comment custom field now. It triggers a deployment resource update and changes the comment property:
Note that the property is visible on the GUI now.
Wrap-up
In order to update a custom property, we also need to change any property that is an input of the create and update workflows. This can be the property itself, by adding it as an input to these workflows (as in the example above).
But if we want to keep it hidden off the GUI, we can introduce another fake input, for example updateVersion. In this case, by changing both the (hidden) property and the updateVersion inputs, we can force a resource update and the custom property value updated at the same time.
You can find the sample workflows at GitHub: https://github.com/kuklis/vro8-packages
com.dynamictypes.vmfolder.package includes the original workflows, and com.dynamictypes.vmfolder2.package the updated versions.