VMware Cloud Community
leowenlu
Contributor
Contributor

dynamically change cloudconfig

we have requirements that we need dynamically change cloud Config during blueprint deployment. So what we have tried so far:
ABX action in vRA will get/setup dynamic settings, then write back/outputs to 'customProperties.cloudConfig', the subscription event topic we have tired both 'compute alloction' and 'compute allocation.pre'.

We can see that cloudConfig has been changed in 'Deployment' but when we logged into the redhad server(8.2)  we deployed, the serve only had the original cloudInit settings from blueprint.

Reply
0 Kudos
11 Replies
j_dubs
Enthusiast
Enthusiast

I think compute.allocation.pre should work - is your subscription blocking?

Reply
0 Kudos
leowenlu
Contributor
Contributor

1.  The Event topic for 'Subscriptions' is 'compute.allocation.pre' , and blocking: Yes
2.  The deployed RHEL 8 had the original cloudConfig, not the one I would like to change to.
3.  code in 'action' (python) is below to return the changed cloud-init
    outputs = {}
    outputs["customProperties"] = inputs["customProperties"]
    outputs["customProperties"]["cloudConfig"] = newCloudConfig  # changed cloudint
    inputs["customProperties"]["cloudConfig"] = newCloudConfig
    print(f"Change cloudConfig new input is : {inputs['customProperties']['cloudConfig']}")
    return outputs

from the action log I could see 'newCloudConfig' is the dynamic changed cloud-init setting, and printed in the log. Now I think the code didn't change 'cloudConfig'  at all, even in the code, I tried to do so.  
Reply
0 Kudos
jimmyvandermast
Hot Shot
Hot Shot

Not sure, but what do the logs say when you do:

 

outputs = {}
outputs["customProperties"] = inputs["customProperties"]
outputs["customProperties"]["cloudConfig"] = newCloudConfig # changed cloudint
print(f"Change cloudConfig new outputs is : {outputs['customProperties']['cloudConfig']}")
return outputs

Reply
0 Kudos
leowenlu
Contributor
Contributor

outputs["customProperties"] = inputs["customProperties"]outputs["customProperties"] = inputs["customProperties"]
inputs["customProperties"]["cloudConfig"] = newCloudConfig # changed cloudint
print(f"Change cloudConfig new outputs is : {outputs['customProperties']['cloudConfig']}")
return outputs

 

As above,  I added inputs["customProperties"]["cloudConfig"] = newCloudConfig # changed cloudint 

Print out in the log for 'outputs.customProperties.cloudConfig'  has changed cloud-init as expected, 

Same as the print out in the log for 'iutputs.customProperties.cloudConfig' has changed as well.

However in Extensibility.Action Runs.Details, I can see the cloudConfig in 'Runtime Inputs'  stayed the original unchanged, variable 'Outputs' has changed cloudConfig.

 

Reply
0 Kudos
jimmyvandermast
Hot Shot
Hot Shot

That's strange behaviour.

Can you go back one step and simply test if a normal outputs change works (not the specific cloudConfig)?

Is SomePropertyToUpdate set to newCloudConfig here:

    outputs = {}
    outputs['customProperties'] = inputs['customProperties']
    outputs['customProperties']['SomePropetyToUpdate'] = newCloudConfig;
    return outputs
Reply
0 Kudos
leowenlu
Contributor
Contributor

 normal outputs change works as expected, also   ["customProperties"]["cloudConfig"] value changed as well, but what confused me is that what was setup to the deployed is the original 'cloudConfig' not the settings  has been changed.

Reply
0 Kudos
leowenlu
Contributor
Contributor

continue with the above.

Then the question except for the cloudConfig settings in the blueprint, is there a way to change cloudConfig during the deployment.

Reply
0 Kudos
jimmyvandermast
Hot Shot
Hot Shot

Ah sorry, misunderstood.
So the property value changed as expected but still the VM receives the original cloudConfig.

Reply
0 Kudos
wouter_asr
Contributor
Contributor

I see the same behavior in our environment, the cloud config shows updated in the UI, but the datasource fed to cloud-init is the original containing the temporary tokens I replaced. Is there any solution?

Reply
0 Kudos
wouter_asr
Contributor
Contributor

Solved! It needed to go in compute.allocate.pre instead of compute.provision.pre

Reply
0 Kudos