If you ever want to start an interoffice hunger games struggle, suggest changing your corporate hostname standard. If you do succeed to move forward on a new naming standard, getting there by committee makes Brexit look easy. I started researching this topic expecting to show the limited capability of the vRA built-in custom naming and then diving directly into vRO event broker workflows to meet those pesky hostname requirements. I was surprised how far I could get using only native vRA constructs to meet a naming standard and saving the vRO implementation for another day.

Here is the naming standard I am using which lets me identify several meta data items from just the name:

< Environment >< OS Type > – < Project Code > – < Server usage ><###  Sequence>

• Environment – first initial of environments ( devl/test/staging/prod)
• OS Type – first initial of windows/linux
• Project Code – unique 3 digit value added as custom property on each project
• Server usage  – (a/d/w/k) for application, database, web, or container server
• <### Sequence > – 3 digit number

For example – a development photon server running containers for project Tango which has a project code of CAS:

dl-cas-k001

First look at the Custom Naming on the projects shows it is fairly limited. Name can be configured to use various properties from the project, resource, endpoint and generated sequence (it says random but it is an increasing number sequence).

The biggest constraint with the custom naming template is user input during provisioning cannot be directly configured on the tamplate and it is not practical for the example naming standard which includes environments, os and server types.

This is where I originally planned to abandon built-in and go custom vRO, but then I started looking blueprint functions capabilities to manipulate the resource name. I set custom name template simply to:

${resource.name}${###}

On the blueprint I added inputs allowing the user to select the for deployment choices and which are also required for the naming standard.

I then leveraged the cloud assembly blueprint functions to build the resource name.  The property value combines inputs, project properties, and functions to build the resource name to meet the standard. Here is the expression set for the name property on the resource to meet the naming standard (full blueprint is provided at end of post for reference):

    properties:
      name: '${input.environment}${substring(input.image,0,1) == "w" ? "w" : "l"}-${to_lower(resource.network.projectCode)}-${input.servertype}'

I did hit an interesting gotcha. The project custom property (projectCode) is automatically injected to all resources, but it appears to be an ordering issue if attempting to use “self.projectCode”.  I had to reference it from the network resource which is always configured before the VM resource.

As you can see from the deployments the servers are getting named according to standard based on the requests.

Project Lab:  Production, windows, database server

Project Pacific:  3 Staging, centos, container servers

Project Tango: 2 Development, centos, application servers

The VM’s are also registered in DNS with the generated name:

At this point I still do not have any validation against DNS, AD, or CMDB to check if the names are unique and the objects do not exist. Hoping this validation becomes part of the custom name ability in vRA in future releases. I would have to default back to vRO/ABX today.

Would I use this for a large environment? No. I need the validation. vRO could be used to integrate with a hostname service or even provide a hostname service via XaaS for manual builds. This method would require modifying of all blueprints if a standards changed and is error prone depending on the blueprinter as well. But this proved to be an interesting experiment in the lab and forced me to learn the functions and expressions available on the blueprint.

Blueprint with inputs and functions:

formatVersion: 1
inputs:
  image:
    type: string
    title: Operating System
    description: The operating system version to use.
    enum:
      - centos
      - photon
      - windows 2016
      - windows 2019
    default: centos
  size:
    type: string
    title: Size
    description: How big do you need it.
    enum:
      - small
      - medium
      - large
    default: small
  environment:
    type: string
    title: Environment
    description: Target Application Environment
    oneOf:
      - title: Development
        const: d
      - title: Test
        const: t
      - title: Staging
        const: s
      - title: Production
        const: p
    default: d
  count:
    type: integer
    title: Count
    description: Number of VMs
    maximum: 8
    minimum: 1
    default: 1
  servertype:
    type: string
    title: Server Usage
    description: Server usage for VM
    oneOf:
      - title: Webserver
        const: w
      - title: Appserver
        const: a
      - title: Database
        const: d
      - title: Container
        const: k
resources:
  vm:
    type: Cloud.vSphere.Machine
    metadata:
      layoutPosition:
        - 0
        - 0
    properties:
      customizationSpec: '${substring(input.image,0,1) == "w" ? "windows" : "linux"}'
      image: '${input.image}'
      name: '${input.environment}${substring(input.image,0,1) == "w" ? "w" : "l"}-${to_lower(resource.network.projectCode)}-${input.servertype}'
      flavor: '${input.size}'
      count: '${input.count}'
      networks:
        - network: '${resource.network.id}'
      attachedDisks: []
  network:
    type: Cloud.vSphere.Network
    metadata:
      layoutPosition:
        - 1
        - 0
    properties:
      networkType: existing

 

Until next time…

Anytime you learn, you gain. -Bob Ross

• vmware
• vra