Of late I have been working on a number of Cloud Templates that require quite an extensive set of custom properties to be set. These custom properties are used to enable further configuration to take place during the deployment process. Additionally, some contain computed values that are then sent to external systems such as CMDBs when deployments complete, through the use of extensibility actions. Through this process, I have found that quite often a common set of custom properties are needed across cloud templates and can be logically grouped into categories, for example, information for a CMDB in one logical group, whilst information to customize a virtual machine post deployment, naturally sits in another logical group. Maybe it would be easier if I showed you a basic example. Why have these properties? It doesn’t matter, it is an example!

CMDB Custom Properties Logical Group

• Deployment name
• Deployment date
• Requestor
• Business unit

Deployment Custom Properties Logical Group

• VM Notes entry
• Operating System

 

Clear Coding

To quote Peter Griffin, something that really ‘grinds my gears’, is lots of messy, disorganized code. Code, in any language should be written in a simple expressive manner, whereby anyone reviewing the code can understand what it is trying to do, without having to consult a further document. This principle is just as valid in your Cloud Templates. Lets take a look at a Cloud Template with our custom properties in it.

formatVersion: 1
inputs:
  businessUnit:
    type: string
    title: Business unit
  vmNotesEntry:
    type: string
    title: VM Notes entry
resources:
  Cloud_vSphere_Machine:
    type: Cloud.vSphere.Machine
    allocatePerInstance: true
    properties:
      image: ubuntu
      cpuCount: 1
      totalMemoryMB: 8192
      storage:
        constraints:
          – tag: storage.profile:gold
    networks:
      – network: ${resource.Cloud_vSphere_Network.id}
      assignment: static
    deploymentName: ${env.deploymentName}
    deploymentDate: ${env.requestedAt}
    requestor: ${env.requestedBy}
    businessUnit: ${input.businessUnit}
    vmNotesEntry: ‘${input.vmNotesEntry}’
    operatingSystemType: ‘linux’
  Cloud_vSphere_Network:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing
      constraints:
        – tag: network.profile:management

Granted, it doesn’t look too bad. However, some the Cloud Templates I have been working on have a minimum of 20 custom properties. At to make it worse, when they were written (not by me!) the custom properties weren’t grouped logically as they are above. The properties for each of our logical groups are muddled around. So, how can we push the concept of grouping and consistency on to our fellow Cloud Template authors and, indeed, on ourselves?

Custom Property Grouping – 101

Did you know that you can group your Custom Properties? When you think about it, it is perfectly obvious that this can be done. For example, when we configure our resources, the resource object has nested properties. The Properties on a resource itself contains nested properties. Therefore, we should be able to nest our own shouldn’t we? Lets take a look at the below. The Cloud Template YAML is the same as the previous example, but this time, I have grouped logically, the properties.

formatVersion: 1
inputs:
  businessUnit:
    type: string
    title: Business unit
  vmNotesEntry:
    type: string
    title: VM Notes entry
resources:
  Cloud_vSphere_Machine:
    type: Cloud.vSphere.Machine
    allocatePerInstance: true
    properties:
      cmdbProperties:
        – deploymentName: ${env.deploymentName}
        – deploymentDate: ${env.requestedAt}
        – requestor: ${env.requestedBy}
        – businessUnit: ${input.businessUnit}
    deploymentProperties:
        – vmNotesEntry: ‘${input.vmNotesEntry}’
        – operatingSystemType: ‘linux’
    image: ubuntu
    cpuCount: 1
    totalMemoryMB: 8192
    storage:
      constraints:
        – tag: storage.profile:gold
    networks:
      – network: ${resource.Cloud_vSphere_Network.id}
     assignment: static
Cloud_vSphere_Network:
  type: Cloud.vSphere.Network
  properties:
    networkType: existing
    constraints:
      – tag: network.profile:management

With our custom properties organized into groups within our YAML, we can now find information easier, both when reading the YAML itself as well as when we want to extract values for use in extensibility. Your custom properties are provided as objects within an array, which is simple to iterate through from vRO or an ABX action.

Why Should I Care?

Using a standard, template approach when writing your YAML is just as important as ensuring good code quality and standards within your vRO and ABX code. Before you start writing your cloud templates, stand back and think about the other parts of your business you are going to need to integrate with. Maybe people will need some level of automation through extensibility to feed information into a CMDB, or a ticketing system such as JIRA. Indeed, someone may need to manually locate information on a deployment. So, think about a structure that maps these requirements and group properties under a relevant ‘heading property.’ It will save you time in maintenance, reduce ongoing complexity and help you and your team adopt a standard template process. Need to know where a property is later on? You will know exactly where to locate it. The importance of standards should not be understated.

So go and give your YAML code a spring clean and de-clutter! You will feel much better for it afterwards.