Configuring OneFuse Custom Resources for vRealize Automation 8



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!


  1. Custom resources are only available in vRA 8.2+
  2. OneFuse version 1.2+. This can be verified from the initial login screen in the OneFuse appliance
  3. 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


  1. 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. 
  2. 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:
  3. 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. 
  4. 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).
  5. After creating the OneFuse:Name element in the Cloud Template, we now have an empty OneFuse:Name element that needs to be built out. 
  6. 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’.
  7. 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. 
  8. 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. 
  9. Now we can submit a request for the Cloud Template.
  10. Once the request is complete, the requestor can view the provisioned name directly in the Deployment canvas:
Questions or comments? Visit our

Comments are closed.

Skip to toolbar