Change a value in vRA cloudconfig from a vRO workflow

[rlabinot]

Hello all,

I want to custom the hostname of my automated VMs and for this I am using cloudconfig with vRO. The vRO workflow communicates with a third-party solution to get an unique hostname in the infrastructure. I want that the workflow set the hostname to the VM by editing a value in cloudconfig.

I am using vRA 8.1 and I have currently this blueprint using cloudconfig :

resources:

  Cloud_vSphere_Machine_1:

    type: Cloud.vSphere.Machine

    properties:

      image: '${input.image}'

      flavor: '${input.flavor}'

      hostname: ${input.hostname}

      networks:

        - network: '${resource.Cloud_vSphere_Network_1.id}'

      cloudConfig: |

        hostname: ${input.hostname}

This blueprint is passed to a vRO workflow at pre-allocation event. The workflow has "inputProperties" as input and "customProperties" as output. The workflow gets a unique hostname and set the value of "hostname".
(vmHostname is the new unique name to set)

The problem is that when the cloudconfig is passed to the vRO workflow, the variable inputProperties.customProperties.cloudconfig has already set the default value for hostname.

So I can change the entire cloudconfig value since it is a string but I don't find it optimal. Is there a way to change ONLY the hostname variable in the cloudconfig with vRO workflow ?

You can see there that cloudconfig has the default value "newName". It was set at the moment when vRA passes variables to vRO.

To bad that cloudconfig is not a "Properties" type, I could have change the value by just typing "custom.Properties.cloudconfig.hostname = myNewHostname".

[rlabinot · Accepted solution]

I thought about a regex that catch only a part of the string and change it but it's not so optimal.

I took the problem differently since we can't edit only a part of the cloudconfig from a vRO workflow because it is just a string. Changing the whole string value will break the user cloudconfig.

If we can't edit only a part of the cloudconfig, a good workaround in my opinion is to add the customized part at the beginning of the cloudconfig value.

In this way, a user can make any cloudconfig he wants and we will just add the "hostname : newName" at the beginning to not break his cloudconfig.

This is what I did and it's working, see here an example.

Random cloudconfig from a user :

Adding the customized part of cloudconfig in the workflow :

"\n" meaning a carriage return. This permit to the user to keep his cloudconfig indentation and at the end he will get this :

      cloudConfig: |

        hostname: newUniqueName

        runcmd:

          - echo "test"

          - echo "vRA"

        final_message: "test vRA"

For the moment, this is a good workaround waiting for better solution.

[ElVirtualJefe]

I hate to revive an old thread, but is this still working for you?

I have 8.10.2, and am doing something similar to this in the compute.allocation.pre phase.  However, I am finding that once I get to the compute.provision.pre stage, my cloudConfig is reverting back to what is in the actual blueprint.

I'm just curious if you have experienced this, and how did you resolve it...?

[dlof]

Just a thought. Is it not possible to use an input property or custom property variable in the cloudconfig properties?

For example, you have input or custom property myhostname and can set this property in vRO. In the cloudconfig you could have:

cloudConfig: |
  hostname: "${input.myhostname}"
...

or 

cloudConfig: |
  hostname: ${self.myhostname}
...

[V00Z11]

@ElVirtualJefe 

Did you ever find a solution to this?

I have the exact same issue. I can change any other custom property but not the cloudConfig.

[V00Z11]

Since I had the same issue I opened an SR. 

The name of the property to update cloud config via Extensibility changed between two releases (some time before 8.12). The new property is called "__computeConfigContent".

Here is an example from GSS in Python.

def handler(context, inputs):
    outputs = {}
    outputs["customProperties"] = {}
    cloudConfig = inputs["customProperties"]["cloudConfig"]
    outputs["customProperties"]["__computeConfigContent"] = cloudConfig.replace("ADMINPASSWORD","MyPassword")
    return outputs

If cloudConfig contains references to "self" or "resource" in any section of the script (not only runcmd, in any section / module of the script), the cloudConfig is overriden at a later stage, so changes done via extensibility are not persisted. If cloudConfig contains references to "input" or "env", the changes via extensibility are kept.