Rename or influence generated name on a deployment catalog resource in vRA7

[dcoulter]

Attempting to use vRO7 to rename or programmatically influence the name (post request) of a vRA7 deployment catalog resource, which is the artifact of a completely provisioned composite blueprint request.

The deployment name defaults to blueprint name appended by dash then a generated 8-digit number, e.g. bpname-12345678.

The UI doesn't give you the option to rename a deployment, only change owner/lease.

Tried vCACCAFECatalogResource.setName() - doesn't fail, just doesn't update.

Looks like there's also a _deploymentName property you can set on a blueprint, but I don't see any API methods to modify this property after the request is submitted.

[jhturver]

Hi,

Did you ever get anywhere with this?

I've looked at the RST API but cannot detemrine a way to retrieve the Deployment object, let alone manipulate it.

Many thanks

Justin

[GrantOrchardVMw]

You can do a write back to that property name at PRE Building Machine, but you can't modify it after provisioning.

[jhturver]

Hi Grant,

I've tried that at BuildingMachine - PRE but it has no influence on the value?

If I set it statically or as an input on the request form it works

So is this property a little like __ReservationPolicyID where it has to be set at the time the request is submitted?

Should I be writing it back at a different (earlier) state?

Many thanks

Justin

[GrantOrchardVMw]

Apologies, you're quite right. Can you try assigning it to PRE VMPSMasterWorkflow32.Requested?

[jhturver]

Hi Grant,

Tried that to no avail - both PRE and POST

I can see that the _deploymentName custom property is being written correctly (based on code in the vRO workflow called at VMPSMasterWorkflow32.Requested) because it comes through as part of the payload at the BuildingMachine phase, but the deployment name is not updated.

Looks like trying to dynamically update __reservationPolicyID in this state phase operates similarly - i.e. it doesn't actually get honored even though it comes through as part of the payload in later phases.

Any way to get some clarity on how these types of properties function, and whether it is worth continuing to investigate ways of updating?

Maybe a REST call of some kind at "VMPSMasterWorkflow32.Requested" would achieve the desired result (vs using "virtualMachineAddOrUpdateProperties.put(propName,propValue)"?

Kind regards,

Justin

[GrantOrchardVMw]

Yeah, I'll dig into this. The event broker states are something that I haven't put enough time into yet to get a solid handle on how they behave differently to each other.

[jhturver]

The somewhat annoying thing is that if we were running a catalogue item request via a REST call, it would be relatively easy to manipulate any of the request properties

e.g. see:

http://www.virtualvcp.com/vmware-vrealize-automation-vcac/220-vro-vra7-catalog-item-provisioning-req...

https://communities.vmware.com/thread/537748

or

http://dailyhypervisor.com/vmware-vrealize-automation-vra7-infrastructure-as-code-iac/ (adding/changing the _deploymentName property to the root of the request JSON template, __reservationPolicyID also works)

I’ve tested updating the _deploymentName field at the root of the JSON request using this method and it works fine

It’s when we use the default IaaS functionality and associated event states to update some of the newer request properties that it gets a lot more complicated and poorly documented (or not possible?)

REST and JSON requests aside, one thing I’ve noted which might be of use is a new (?) vRO scripting class: vCACCAFEDeploymentResourceRequest which has a “setDeploymentName” property – but there is absolutely no documentation that I can find on accessing/using this

Any assistance appreciated

Cheers

Justin

[Craig_G2]

Stuff like this is killing me too..

The inability to set __reservationPolicyID (and other similar properties) at REQUESTED pre/post means having to resort to XaaS blueprints to request the IaaS ones.

It's good to see that other people are experiencing the same issues, so maybe these will be addressed in the future 🙂

[alexanderjn]

Trying something similar but at request time. I'd like to have the deployment name have some meaning, (more than "blueprint-name_########").

Given the bulk-import restrictions regarding Deployments:

- Each machine must be imported to its own deployment.

- You cannot import a single virtual machine to an existing deployment.

- You cannot import multiple virtual machines to a single deployment.

...along with the fact that we have no multi-vm blueprints, I'd like to have new requests from the UI automatically set the value of _deploymentName to the value of Hostname (or even blueprintName-Hostname).

Haven't figured out how to do that so I filed a ticket with GSS.

Mind if I ask what naming scheme you're looking at for Deployments?