Automatic Deployment Names in vRA 8.x

A good thing about working with customers on a regular basis is that they provide you with plenty of opportunities to learn something new or find something out. Personally, I relish that sort of problem solving.

While I was given a demonstration to one of my recent customers, they asked about the deployment name setting in vRA 8.x. If you're not familiar with it, a deployment is like a building. It's created using resources in a defined manner based on a template (or blueprint). Just like a building, each deployment has its own unique name (the equivalent of a building's address).

In vRealize Automation, deployment names must be unique and one must be supplied at request time.

This is true of a deployment created both through Cloud Assembly or through Service Broker. The dialog will tell you if the name has already been used.

Getting back to my customer, they asked me if there was a way to automate / hide the deployment name field. Their users would not want to have to fill this in. In Cloud Assembly (where templates are created, infrastructure is configured etc) there doesn't seem to be an easy way to do this. However, their users would predominantly be using Service Broker where this is possible using a custom form.

Custom Forms

Custom Forms are a mechanism by which the default functionality or presentation of a cloud template can be altered, usually to make it more user friendly or guard against incorrect selections or entires being made in to a request.

Looking at a custom form created for the same cloud template used above, you can see that the Deployment Name field (highlighted) has automatically been added to the form.

If we do nothing else then the field will be presented as before on the form and the user will have to enter a unique deployment name. However, if we examine the field's properties, there there are some options that we can explore.

The Values tab controls how the field is populated. By default there is no default value and the value source is a constant. Clearly there are options for the value source however. The link below will take you to the documentation page that defines them.

Custom form designer field properties in vRealize Automation Service Broker

The field properties in vRealize Automation Service Broker determine how the fields looks and what default values are presented to the user. You can also use the properties to define rules that ensure the that users provide a valid entry when they the item in the catalog.

VMware Logocnugent

Of the five options described, either External source or Computed value look like they will suit our needs.

Computed Value

If you read the documentation above then you'll know that this will allow us to concatenate a number of string values or manipulate integers with basic mathematical operations. Sounds good.

But because the deployment name field expects a string we're limited to concatenation. This means constants or other field values can be used. As an example, we could make a deployment name based on:

• The catalog item name
• The environment selected (one of my other inputs)
• The ID of the user requesting the deployment

This would look like this:

And when requested it would produce a deployment like this:

Although we could technically now hide the Deployment Name field, unfortunately we haven't solved the problem completely. Using the computed value option in this manner will only allow each user to request the catalog item once per environment. That may be ok for some use-cases, but for my customer this would be a non-starter.

External Source

Now let's try the External source. For vRA, this means an action in vRealize Orchestrator (vRO). We have a couple of options to consider here.

1. We could simply generate a completely random text string. This would certainly be likely to create unique deployment names. However, it wouldn't be very user friendly as those names would be shown in the user's list of deployments.
2. We could generate a name based on a number of constants or user selections and add some random text to it to ensure uniqueness. This would be my preferred option.

(Note: With the first option we could rename the deployment at a later stage, that'll be a post for another time however.)

First we have to decide what constants or options we want to use. In the cloud template I've been using, the following are available:

The request info fields are common to any catalog item request, as is the Project field on the canvas. The Environment, System Role and IP Address Allocation fields are specific to the cloud template in use.

In the end I have selected to go with:

<Catalog Item Name> -<Environment>- <Unique Text>

So now I can create a vRO action that does this for me. I'm not going to go in to detail on how that's done, but you can see the action in Orchestrator below:

The important points to note are:

1. The return type is a "string" - this is what vRA will expect for the Deployment name field.
2. The first input is also a string (called catalogItemName) - this will be mapped to the equivalent field (see above).
3. The second input is a string (called environment) - this will be mapped to the equivalent field (see above).
4. The "unique text" actually comes from an ISO formated date. It's not 100% guaranteed to be unique, but because of the inclusion of milliseconds, it's very unlikely that two deployment requests will happen at exactly the same time.

If you want to reproduce this action, or avoid eye strain then the script part of it is below:

Once this is saved, we can head back to our custom form. The source for the Deployment Name field is set to "External source", the action we created is selected and we map the two inputs to the relevant fields.

One final step, over in the Appearance properties we need to change the visibility of the Deployment Name field - change from "Yes" to "No".

Save and enable the custom form and head over to the catalog in vRA Service Broker. When requesting the catalog item, you'll see that the Deployment Name field is not visible:

What's more, when we submit the request we get a unique Deployment Name automatically set:

During another request, I changed the option for the environment from "Development" to "UAT". The Deployment Name value was set accordingly: