Request vRA Actions on Behalf of other User with vRO.

Request vRA Actions on Behalf of other User with vRO.

Hello Team – This is an updated to the 3 blog’s i had done for Auto-Scale workloads with vRO, vRA and PowerCLI.

If you have not seen it, please have a look here.

Auto-Scale vRA workloads with vROPS,vRO and NSX

AutoScale vSphere Workloads with vRA and PowerShell based NetScaler NITRO API’s

VMware WebHook Shim and AutoScale with vRO

Well all was working well, but during our test POC setup of this i saw that it used to work perfect when i logged in via my administrator account in my vRA portal and showcased this solution.

But there were some gotchas when an autoscale action had to be performed for another end user who had logged in to the vRA portal.

Well the problem faced was even though when an end users VM’s performance get’s hit via CPU or the load coming to it via the NSX load balancer – and the auto-scale requests start, the end user won’t see anything in his requests tab – it would be just blank with no data at all on whether a scale out request was invoked or not

Here’s an example of the same, as you can see when we log in via an end user account i don’t see any details on scale-out request being shown, it just shows blank!

But when i head over to vRO, i am able to see that the workflow has already kicked in and is in the process of scaling out this deployment by adding a new VM and is waiting for the resource action to complete.

And after some time when the above request completes we would see a new additional VM created in the deployment view.

After digging around this issue for quite some time, i had a chat with my good friend Sajal Debnath where he suggested to use Per-User session to add the vRA host in vRO which effectively means that the credentials to run the workflow are extracted from the currently logged in user

We updated this option in the workflow , but after trying this too i saw the workflow was failing , even-though the alerts come in and trigger the workflow.

Well after digging deep into this problem, i saw that there was another action available which allows us to

“requestResourceActionOnBehalfOf”

another user , rather than just requesting an action with

“requestResourceAction”

This basically solved the entire issue!, what i did now was now to make a copy of the “Submit to vRA” workflow which is the final step to invoke the scale action,  edited it and replaced the requestResourceAction with requestResourceActionOnBehalfOf

And voila!, as you can see below this action expects a new input too called the user name, which is basically pointing to the owner of the VM.

Now to get the owner name of the VM, i just added the below line of code into the “Prepare Properties” scriptable task so that it can also be passed along to the requestResourceActionOnBehalfOf action as an input to the user parameter 🙂

Now after making all these changes i went ahead and again generated some load on the VM’s which would now trigger an alert, this alert would be captured by Web-Hook Shim which would lead to the invoke of the desired workflow.

But i saw that even though the workflow was started it abruptly failed with the below error.

Resource operation not found!

Now to solve this issue i had to do a ton of research as the vRO logs cant be understood that easily and require some deep level experience with the product and other worldly powers! 🙂 (En Sabah Nur – aka Apocalypse ) and of course google did not help this time 🙂

The change i had to make is to again run the vRO workflow to update the vRO host and select Shared Session.

So what now this effectively means is that all the workflows called for vRA would be using the administrator credentials to invoke the workflow in vRO.

I was able to see this in the log’s next time the workflow got invoked! for a scale-out request.

Now when i logged into vRA under that user account i was able to see that indeed we can see the Requests showing up and the submitter name was the administrator account which was calling the vRO workflows internally 🙂 .

What a relief !!, finally its working now – Also note in your production setup you can create a dedicated svc account for vRA called svc-vra use that in place of the administrator account as i had used in my POC setup and all future scaleout / scale in request when they get invoked would show the submitter name as svc-vra and hence the vRA admin and the end user can make sure and be at peace with each other as the SVC account is invoking these workflows and not done by any other end user / admin 🙂

You can find the updated package here

I hope you enjoyed this blog post and found this information useful.