Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
In the “Getting Started with the OneFuse Property Toolkit” article we looked at ways the property toolkit can be leveraged to help standardize configurations across platforms. We also look at a few of the capabilities that it offers. In this article we are going to look at some of the ways the Property Toolkit can be utilized within vRA8.
vRA8 Property Stack
vRA8 much like its predecessor vRA7 has the concept of a property stack that lives with the deployed machine throughout its lifecycle. Although there are some significant differences between how the two versions manage the property stack across different lifecycles, we are not going to dig into those details in this article. For this article we are going to talk about the property stack in general terms.
Within the current release of vRA8 there are two places properties can be defined. They can be defined on a project or within a blueprint. The concepts in this article apply to both.
Assign OneFuse Property Sets using static properties
Adding a OneFuse Property Toolkit Property Set to a vRA8 blueprint is as easy as defining a standard property on the blueprint. There are a few things to be aware of as outlined below.
The property name must be formatted as OneFuse_SPS_{something_unique}. The OneFuse_SPS_ portion of the property name tells the OneFuse workflows that this is a OneFuse property toolkit property that will reference a OneFuse Property Set and the {something_unique} part allows us to define multiples of them. The value for the property will be the name of the Static Property Set that you have created in OneFuse.
I have a property group named sps_env_prod and this will be the value I will use. It would look something like the following:
- Property Name: OneFuse_SPS_Env
- Property Value: sps_env_prod
Adding this property to the blueprint will add every property defined within the sps_env_prod property set to the property stack for any deployments requested from this blueprint. In my case it will add the following:
{
"nameEnv": "p",
"folderEnv": "PROD",
"ipamEnv": "prod",
"ouEnv": "PRD",
"sgEnv": "prod",
"dnsPolicy": "prod",
"adPolicy": "prod",
"location": "atl",
"dnsSuffix": "infoblox851.sovlabs.net",
"deployNameEnv": "Prod",
"s3NameEnv": "production"
}
Because this is a flat property set everything within it will be added to the property stack within vRA. My next property set that I will add to vRA8 will be a property to define sizing. If you read my article “Getting Started with OneFuse Property Toolkit” you would have seen that within my sizing property set I have nested properties. These are nested under parents and one of those parents is a reserved property that tells vRA8 which properties to include for its platform.
The contents of the sps_size_small property set are:
{
"size": "small",
"cpuCount": "1",
"memoryMB": "1024",
"memoryGB": "1",
"OneFuse_VRA7_Props": {
"VirtualMachine.CPU.Count": "{{cpuCount}}",
"VirtualMachine.Memory.Size": "{{memoryMB}}"
},
"OneFuse_VRA8_Props": {
"flavor": "{{size}}"
},
"OneFuse_TF_Props": {
"cpu": "{{cpuCount}}",
"memMb": "{{memoryMB}}"
},
"OneFuse_TF_Props": {
"vcpu": "{{cpuCount}}",
"mem_size": "{{memoryGB}}"
}
}
Unlike the sps_env_prod property set not all of these properties will be written against the deployments property stack. Only the parent level properties; cpuCount, memoryMB, and memoryGB as well as the properties located under OneFuse_VRA8_Props; flavor will be written against the deployments property stack.
The final property set I will add in this example is one that I use for defining applications. In this case WordPress will be the application. The property set will be sps_app_wordpress.
The contents of sps_app_wordpress are:
If you look closely you will see that within this property set is another property set property and value. This will result in the contents of the sps_os_centos7 property set also being pulled in as part of the deployments property stack.
The contents of sps_os_centos7 are:
{
"nameApp": "web",
"ipamApp": "web",
"OneFuse_SPS_OS": "sps_os_centos7",
"deployNameApp": "WORDPRESS"
}
Just like with sps_size_small only the parent level properties as well as the properties located under OneFuse_VRA*_Props will be added to the deployments property stack. At this point all the relevant properties from each group will become part of the deployments resultant property stack and impact the deployment. In this case some affect vRA8 capabilities and others will impact OneFuse module integrations.
Assign OneFuse Property Sets using inputs
Being able to have your vRA8 consumer make a single selection and that in turn drive multiple properties into the request has to be the most game changing capability introduced into vRA. For years I have been helping organizations drive vRA more dynamically and reduce the number of blueprints they have to create and manage and it’s largely due to the capability. To fully embrace this model using our other modules in conjunction with the Property Toolkit and OneFuse methodologies, but this is a great start.
Assigning OneFuse Property Sets using vRA8 inputs is super easy. If I use the same property sets we have already looked at earlier in this article I only need to make some minor changes.
To start I need inputs for the users to make selections.
Next I need to be able to use those inputs to drive my OneFuse Static Property Set selections. I am able to do this through the use of blueprint expression syntax.
When a user selects an environment it will complete the sps_env_ with whatever they selected to attach the appropriate OneFuse Property Set. The full blueprint yaml is below:
formatVersion: 1
inputs:
machineCount:
type: integer
default: 1
maximum: 5
minimum: 1
title: Number of Machines
env:
type: string
description: Select an environment
default: test
title: Environment
oneOf:
- title: Development
const: dev
- title: Test
const: test
- title: Production
const: prod
app:
type: string
description: Select the application to deploy
default: linux
title: Application
oneOf:
- title: Linux
const: linux
- title: Windows
const: windows
- title: Apache Server (Scripting)
const: apache
- title: Apache Server (Ansible Tower)
const: apache_ansible_tower
- title: IIS
const: iis
- title: SQL Server
const: sql
- title: WordPress
const: wordpress
size:
type: string
description: Select a size
default: small
title: Size
oneOf:
- title: Small
const: small
- title: Medium
const: medium
- title: Large
const: large
resources:
Cloud_vSphere_Machine_1:
type: Cloud.vSphere.Machine
properties:
#vRA Properties
imageRef: Centos7
cpuCount: 1
totalMemoryMB: 1024
#OneFuse Module Properties
OneFuse_NamingPolicy: 'onefuseblog:default'
OneFuse_IpamPolicy_Nic0: 'onefuseblog:default'
OneFuse_DnsPolicy_Nic0: 'onefuseblog:default:{{dns_suffix}}'
OneFuse_ADPolicy: 'onefuseblog:default'
#Property Toolkit Property Sets
OneFuse_SPS_Env: 'sps_env_${input.env}'
OneFuse_SPS_Size: 'sps_size_${input.size}'
OneFuse_SPS_App: 'sps_app_${input.app}'
This just scratches the surface of what is possible with the OneFuse Property Toolkit. Stay tuned for some more great content and exciting use cases. Remember while this article demonstrated consuming OneFuse property sets with vRA8 these property sets can also be consumed from vRA7, via our Terraform Provider, as well as the OneFuse API.