Might be a little ambitious, but does anyone know if there is way in vRA 7 / vRO to trap and update the IaaS Catalog Item request object after it is submitted by the user in the GUI, but before it's submitted to the system?
This post shows how the request object can be modified in vRO when the IaaS request is made via code (i.e. run code to make, modify, and submit the request) rather than request it through the vRA IaaS GUI:
But I'm trying to determine if there's a way to do something similar by getting a handle to the request object via an Event Subscription trigger, after the IaaS form has been submitted to the user, but before it's submitted to the system.
This will enable properties such as the _deploymentName (parent level), or __reservationpolicyID and others that cannot normally be modified after the Catalog Item request has been submitted, to be dynamically updated in vRO code.
I've tried various code run at different state phases (e.g. MachineRequested - PRE, POST, and EVENT) but any changes made to properties seem to be ignored in terms of the resulting values of the Deployment/machines.
e.g. this does not log an error at any of those phases listed above, but has no effect on the deployed configurations values:
requestIdBase = virtualMachineProperties.get("__Cafe.Root.Request.Id");
var myCatalogItemRequest = vCACCAFEEntitiesFinder.getCatalogItemRequest(vraHost,requestIdBase);
System.log("Catalog Item Request object: " + myCatalogItemRequest);
I don't want to revert to using an XaaS blueprint/Catalog Item and doing something similar to the author above, because of the extra functionality and richness the IaaS request form provides at this stage.
Appreciate any thoughts/ideas ....
What exactly is it you need to modify ?
The way I have done this for a customer is by using approval policies. For instance, it wasn't possible to create network profiles so all VMs were connected to external portgroups and IPAM had to be managed by an admin team - who essentially had a spreadsheet of available IPs.
So a requestor requested a virtual machine and the approver had to enter the IP details such as IP, subnet, gateway, DNS etc.
Same applies for resource changes - the requestor was only able to request a standard-sized VM, but the approver was able to change the resources of the VM to be deployed ..
Makes sense ?
I'm in a similar position. I need to catch the request before the allocations are made by the system.. Adding an XaaS form in front of the IaaS form adds so much complexity for the customer... But there doesn't seem to be any other way around this.
Is the "system" in this case the requested VM provisioning in vCenter? If so, in your event broker trigger flow you could try to:
1. Get the virtual machine ID from the properties object that vRA sends over to vRO from the event broker.
2. Gather the virtual machine entity object using the getVirtualMachineEntityFromId action. It looks like you were trying to tweak the catalog item in your original post.
3. Write logic to gather and change the properties of the VM entity you pulled down.
4. Use com.vmware.library.vcac's updateVCACEntity method to apply the changes you made to your manipulated object.
We've been able to tweak a few inbound requests using this order of operations above, including naming and folder placement. This article by DEFINIT also outlines the procedure by changing the VM's name.
Hope this helps!
These are the kind of updates I would like to make - programatically
If there is a better way to do this (i.e. rather than getting the request object itself before it's been submitted, and updating the properties before submitting), then I'd be very keen to understand how
I have a similar issue...
We need to set the networkProfileName [We have different profiles based on the type of VM being built] , but I want to dynamically determine it from other properties, not have users have to select a value from a dropdown. Now I have a workflow that will do this, but the issue is within the MachineRequested - PRE , the Allocations have already been done, so if the networkProfileName is not set, VRA will make it's selection, so it's already allocated a profile/IP address, before we can tell it what we want..
Now I'm looking at going earlier, in the 'Catalog Item Requested' Event, but not sure how I can update the properties in the request from here ?
Thanks in advance,
raptorirl, in short, there is no way to "intercept" the IaaS values in flight and modify them via the EBS. The EBS is invoked after the allocate phase, and by that time it is too late. But your use case I've done very often and it is certainly possible and actually pretty easy using the SovLabs IPAM and Property Toolkit modules. And what you're wanting to do as far as deterministic setting of a network profile based on other conditions, is exactly possible and requires no custom code or manual EBS subscriptions. I illustrate all that in a blog post here. They seem to have lost my images and screenshots, so I'll just attach the Word document here.