In this article, I'd like to elaborate on the ability to dynamically assign custom properties, reducing the number of blueprints. This is very similar in concept to my previous post: Applying a vCenter Customization Spec Dynamically in vRA / vRO, but focuses more dynamic sizing as a principle.
As an example, let's imagine we're a software company, and we have a Template for a Linux Distro, on vCenter. Currently, we're manually deploying each instance.
In our use case, the developers will be using this VM to write and test software configurations, including Apache, MySQL, Java applications and daemons, and PHP.
Now, as the team responsible for automation, we want to allow our developers to request Virtual Machines themselves, without killing our fabric resources.
So, the way we approach this is by introducing 5 sizes: Micro, Small, Medium, Large and Jumbo.
Each size has a corresponding resource assignment association as follows:
- Micro: 1 CPU, 1 GB RAM, 16 GB HDD
- Small: 2 CPU, 2 GB RAM, 40 GB HDD
- Medium: 2 CPU, 4 GB RAM, 80 GB HDD
- Large: 4 CPU, 8 GB RAM, 200 GB HDD
- Jumbo: 12 CPU, 32 GB RAM, 1 TB HDD
We take this principle further by assigning approval policies to Large and Jumbo only.
This will encourage our developers not to use the largest configs unless really needed, in which case managerial approval will be required.
By offering these sizes, the out-of-the-box approach would be to use one blueprint per configuration. In other words, I'll refer to our Linux Distro we are using for the Developers. Let's say it's RHEL 6, for example. We would typically have the following sized blueprints for RHEL 6:
- RHEL 6 - Micro
- RHEL 6 - Small
- RHEL 6 - Medium
- RHEL 6 - Large
- RHEL 6 - Jumbo
If we wanted to add another Distro, the list of Blueprints would become rather large.
We have a single RHEL 6 Blueprint, but we create a custom property on that Blueprint, allowing the relevant size (under the requirements section above) to be selected on request.
Then, we leverage a vRO workflow to read that property and then assign the relevant configuration on-the-fly.
Create the custom property in a Build Profile or on the Blueprint for our Size Selection.
Next, we create a Property Definition for the above property. This tells vRA to render the property as a specific type of control. In our case, we want a Dropdown List:
Note, above, that the Name of the property definition matches the name of our custom property in the previous step.
Next, we need to create the values for the Drop Down list. In the image above, the "Edit" link to the right (in the Property Attribute column) is how we create the values for this Definition. Click "Edit" and enter the following:
Now, we need to ensure that our Blueprint does not allow for entering values for CPU, RAM and HDD. We do this by removing the "Maximum" values for each, as follows:
Great, so now we have a blueprint that probably still works, but it will only assign a single CPU, 1 GB memory and a 16GB HDD no matter what option we select.
Now comes the part where we glue this all together.
You need to have a BuildingMachine Stub Workflow of your own, already configured, and integrated with vRA. If you don't, no sweat, you can find you all you need to get this point by visiting one (or more) of my previous posts on this topic.
Right, so assuming we have our Building Stub WF, we simply need to fetch the property above, and then assign the other relevant properties (CPU, RAM, HDD) accordingly.
Let's go ahead and drag on a scriptable task. Then we'll edit this task and I'll show you how:
In the script above, we're looking for the property on the VM, set by the dropdown we created earlier. This value will be one of the following: Micro, Small, Medium, Large, Jumbo.
In line with this, we are checking to see if the value equals any of these, in which case we are setting a local variable for CPUs, RAM and Hard Disk Space accordingly.
Now, as you may have guessed, this is not yet doing anything to our VM.
This is merely groundwork so that we can determine the values to set.
Below is the other half of this script above:
This is the part that does the juicy bits. Don't worry about all the code, most of this stuff is boiler plate - I simply used the scriptable portions of Actions that already exist in the vRA plugin.
This is the stuff that really does the work here. The System.getModule pieces are really just calling actions and passing in the required parameters.
And, yes, you will see that I have also called the Disk Size piece twice (two different properties).
Furthermore, we are updating custom properties as well as Entity Properties on the actual object itself so that the values trickle down to vCenter when the machine is actually built.
So, it works. I went into vCenter and ensured the values were there and it all works.
We now only need: a single Blueprint allowing us to select sizes like cookie cutters.
The potential caveat
You guessed it. There's almost always a tradeoff.
The challenge here is that normally, vRA does resource / sizing / constraint checking on the reservations to ensure that we have enough space to provision. It's my understanding that this is even before the "BuildingMachine" phase / lifecycle state.
So, what does that mean?
Well, it means that one user may exceed the allotted reservation because at the time of checking, vRA thinks that this VM only has the default 1 CPU, 1 GB RAM and 16 GB HDD as defined in the Blueprint. However, we're modifying those values AFTER the check happened.
Now, there are two ways to overcome this. First, you could set the default values at an average of the most requested sizes, or, you could set the default values to the maximum (Jumbo) which will ensure you never run out. However, this also means that users requesting a Micro or Small will be told there's not enough space on the Reservation if that's the case for the Jumbo.
I hope it makes sense.
Feel free to ping me if you need clarity on
Twitter Handle: @T1gerShark