Configuring OneFuse Custom Resources for vRealize Automation 8
Editor's note (2026): The methodology described in this post is what I now call Decisions as Code. Property Toolkit was the OneFuse implementation of the same idea. See "Decisions as Code" for the current framing.
Introduction
This post will build upon the prior post, Introducing OneFuse Custom Resources for vRealize Automation 8, but will be a lot more hands-on in nature. We’ll show you how to configure the Custom Resources, as well as how to consume them from the vRA canvas to get you started leveraging these advanced capabilities. The objective with this article is to show you how to configure and consume OneFuse modules in vRA Cloud Templates.
We will have some follow on articles covering more in depth use cases, but for this post, we will focus on how to consume the OneFuse modules from the vRA canvas by leveraging the Naming module as our example. Potential future blog topics on how-to scenarios include naming Cloud Assembly deployments, naming for other canvas resources like S3 buckets, DNS records, dynamically creating deployment property sets, storing and referencing deployment-level properties within a cloud template, pre-provisioning network resources among others. Can’t wait for the new articles? In the meantime feel free to reach out if you want to learn more about any of these use cases!
Prerequisites
- Custom resources are only available in vRA 8.2+
The Custom Resources feature is available as part of the standard OneFuse Upstream Provider package for vRealize Automation. This will need to be version 1.2.0+. From the vRO 8 Web Client, navigate to Configurations > OneFuse > UpstreamProviderVersion
OneFuse version 1.2+. This can be verified from the initial login screen in the OneFuse appliance
Configuration
Once the request is complete, the requestor can view the provisioned name directly in the Deployment canvas:
Now we can submit a request for the Cloud Template.
Now we can build out the Cloud Template to allow for the user to select some of the inputs, and some of the inputs are statically set. Some examples follow. Note, for the nameGroup property, we are actually leveraging the OneFuse Property Toolkit to call a Property Set from OneFuse that has the nameGroup property defined in the property set. For more advanced Property Toolkit functionality, we will be covering that in a separate post. In addition, we are also leveraging some of the blueprint expression syntax available in vRA8 to pass the properties as expected.
Up to this point, you may have noticed that there isn’t anything passing in the properties that the naming policy expects. With any of the OneFuse Custom Resources, you can very simply select the ‘properties’ item to see the available input properties for each type. From here, you can see that there is a property called templateProperties that allows you to input an array of properties.
Custom_onefuse_name_1 is way too long of a name, so it gets renamed to just “Name”. I also specify that I want to use the ‘machine’ naming policy (note: the policyName field can also leverage OneFuse Template Engine to dynamically choose the correct policy) in OneFuse and that I want to use the OneFuse endpoint defined in vRO called ‘onefuse’.
After creating the OneFuse:Name element in the Cloud Template, we now have an empty OneFuse:Name element that needs to be built out.
In our lab environment we have the following naming policy defined for machines requested in our environment. This allows us to have one single naming standard exposed to not just Virtual Machines built in vRA, but with the OneFuse Custom Resources, we can now allow a user that may be manually building a physical server the capability to request a custom name for a physical server build leveraging vRA. This prevents naming collisions in our environment as well as standardizing all naming for our environment. In the following steps, we will be passing in the required inputs shown in the Naming template below (nameGroup, nameLocation, nameEnv, and nameOS).
In Cloud Assembly, navigate to Design > Cloud Templates. You can either create a new Cloud Template, or use an existing one. For this example, we will be leveraging a new Cloud Template. If you scroll all the way to the bottom of the pane to the left of the canvas, you will see all of the OneFuse Custom resources. Drag and drop the OneFuse:Name element on to the canvas.
In the Cloud Assembly UI, navigate to Design > Custom Resources. Here you should see the available Custom Resource types. Every one of these elements is now able to be consumed directly from the vRA canvas:
Once you have verified that all of your systems are at the minimum required versions, you can then run the configuration workflow. In the vRO Web Client, navigate to Workflows > Custom Resources > Configuration and run the BETA – Configure OneFuse Custom Resources workflow. There is no form to fill out for this workflow, just run it and it will create all of the required elements for the Custom Resources feature.
