Don’t be shy, admit it – you already used Cloud Automation Services and fell in love with it, didn’t you? One thing you could be wondering about is how to achieve the same level of extensibility as you do with vRA. Probably, you have already found out that you can provide the payload of a request to the SaaS-enabled vRO by using the inputProperties parameter. I guess you’ve been asking, ‘Well, can I have a sort of an outputProperties parameter to talk back to Cloud Assembly and fix a few things in the deployment, like tags or custom properties with the same subscription?’ It turns out you can indeed talk back to Cloud Assembly and this bi-directional conversation you can have is definitely not a small talk! So, straight to the point:
First, we have our blueprint. It’s a tiny simple blueprint with a tag and a few custom properties like the hostname of the machine which can be used later for cloud-init specifications.
inputs:
Hostname:
type: string
default: hostname1
resources:
Ubuntu_CloudInit:
type: Cloud.Machine
properties:
image: NN-EmptvyVM
flavor: Small
hostname: '${input.Hostname}'
tags:
- key: machine
value: vsphere
- key: app
value: wordpress
Then, we have a vRO workflow we need to execute at the post-provisioning of the machine and for now it’s just a simple one – printing the contents of inputProperties.
var value;
for each(var key in inputProperties.keys)
{
value = inputProperties.get(key);
if (System.getObjectType(value) == "Properties")
{
var valueProp = value;
System.log(key + "[");
for each(var valueKey in valueProp.keys)
{
System.log(" " + valueKey + ":" + valueProp.get(valueKey))
}
System.log("]");
}else
{
System.log(key + ":" + value);
}
}
So, what it’s doing is getting the inputProperties and iterating through each key, while watching whether any of the keys is another set of Properties and iterating trough it.
Here are the results:
That was easy. Now, let’s try to change the hostname of the machine with the same subscription and a little different script and workflow.
As you can see, the “hostname” property is part of the customProperties set. What we need to do is first create an output parameter in the workflow called CustomProperties of type Properties:
And at the end of the script we add two lines that append “.vro” to the hostname:
customProperties = inputProperties.get("customProperties");
customProperties["hostname"] = customProperties["hostname"] + ".vro"
No need to modify the subscription. Just create a new deployment and see how the “hostname” property changes. Since we did not modify any of the other properties, they stay the same.
Let’s update the tags of the machine. Currently, the existing tags on a machine cannot be modified with this method – you can only add additional ones. To do this, instead of adding a “customProperty” output parameter, we just have to add a tags one:
The code for providing the tags is similar:
tags = originalTags;
tags.put("machine", originalTags["machine"] + "_vro");
What we do with it is add a new tag that has the same key “machine” but append “_vro” to the value.
You may ask how I know which type of parameter to put here. Just look at the subscription schema – it tells you the name of the parameter and the type itself. Complex type translates to Properties in vRO, and you can also have an array of string or complex.
Now, the natural question arises – “Can I update both the tags and the hostname of the machine with the same subscription?” The answer is yes, absolutely. Just add both output parameters and update as required.
