If you have use vRealize Automation, you probably already know that you can specify the naming template to be used for machines, networks, security groups and disks provisioned in a given project – more at this blog

However with the introduction of vRealize Automation 8.8 and vRealize Automation Cloud April 2022 Release, Cloud Assembly has moved to a new custom naming method. The new method provides you with greater flexibility and additional naming options. It is also much easier to manage the naming across projects

Now, depending of your situation, if you were a beta adopter or a new deployment, deciding to enroll or migrate may have implications that you need to be aware of, so let’s discuss them further and then let’s actually take a peek to the new methodology.

In the November 2021/8.6.1, Cloud Assembly released a beta version of this new global custom naming method, which means that now you may face one of the following scenarios

So Enroll / Migrate ?

To determine if you are using the new method, select Infrastructure > Administration > Custom Names.

If you see the enroll now option

then you must consider your choices.

  • Do not migrate custom names from any projects, enrolls you in the global method. You can create templates and apply them to the organization and projects. Now, keep in mind that after enrollment, the current templates are not longer available. If you plan to use the same format, capture the format before enrolling so that you can create similar templates using the global method.

Right after enrollment, you have no defined templates and you must create the templates to use going forward. Click New Custom Name to get started ( two images above ), then after you created a template and assigned it to the project, under the custom naming in the project, the resource naming templates that apply to this project are listed

  • Migrate custom names for all projects, enrolls you in the custom naming and creates project-level templates for each project. You can manage the templates and apply them to other projects if needed. Now consider that if you have 100 projects and you migrate the templates, you will end up with 100 variations, and it is also very possible that some project templates might fail migration due to unsupported formats.

After enrollment, the defined templates for each project are added to the Custom Names page.

Screenshot of the Custom Names page showing the migrated project-level templates.

the custom naming in the project is updated with the migrated custom naming template for each resource type. The list is for informational purposes. To manage the templates, use the Custom Names

Screenshot of the Custom Naming section of the project which shows the applied custom templates, including the resource type template formats.

Having the Enroll / Migration decisions taken cared of, you can actually start exploring the new global custom naming method, and in this case I will defer to the use case explored at the documentation Create global custom naming for deployed resources in Cloud Assembly, I will say however, that one cool feature is the ability to add naming templates for your different resource types

And even If you do not define naming templates for all resource types, the undefined resource types default to the organization template. If an organization template does not exist, the undefined resource types default to the system naming

And furthermore, the new matching pattern enables you to set a different starting counter value for different resources and in general Custom Names are easier to handle and create.

Conclusion

You can use custom naming templates to override the system naming of deployed resources to naming conventions that you define. The naming is applied at deployment time.

Due to improvements to the custom resource naming methodology, please take a moment to determine the method that is used in your instance of Cloud Assembly and what your next steps should be.