Hi All,
How can I deploy a Blueprint for other users (on behalf is not an option because users has no entitlements for that) in vRealize Automation 7.x?
In vRA 6.x, I had users with no entitlement for services (they can't deploy VMs) and, as a Business Group Admin I can deploy a VM using the Custom Property "VirtualMachine.Admin.Owner" specifying a user, so the deployed VM appears in the user's Items Tab.
In vRA 7.x this doesn't work neither setting the property in the Deployment nor the Virtual Machine. The deployment and the Virtual Machine appears in the Admin's Items Tab rather than the User's.
Thanks a lot,
Hi Damián,
Can you explain what you're trying to achieve as the end result? When you say
on behalf is not an option because users has no entitlements for that
do you mean the end user has no access to vRA at all?
I'm trying to follow how you want this to work and what the options might be.
Hi,
In my scenario, users can only manage the VM power cycle, but they cannot deploy new VMs, so they don't have entitlements for blueprints. The Business Group Admin can deploy a VM but we need to change the owner to that user.
In vRA 6.x you can do this using "VirtualMachine.Admin.Owner" custom propery. But in vRA 7.x this property doesn't work and now we need to deploy and then execute "Change Owner" Action.
We'd like to keep doing this in a single call.
Thanks.
D
Is the order taking place through the GUI or through automation? If it's through the GUI did you try updating the value of the On Behalf Of field on the catalog item request page in the upper right-hand corner of the page before submitting the request?
If you're doing it through the API, I think you would need to update the requestedFor field.
In our environment we change the owner at the end of the deployment. We have a quite a few instances where we only allow limited management of the systems by the user and do not allow them to deploy from within vRA. We've always done it this way in both versions 6 and 7.
In our environment, use "On Behalf Of" because users do not have entitlements for deployment.
In vRA6 we could use "VirtualMachine.Admin.Owner" Custom Property but it doesn't work in vRA7.
I know that I can deploy and then "Change Owner", I wonder why I cannot do it as in vRA6.
Using the API and updating the "requestedFor" field has the same effect as On Behalf Off, it doesn't work if the user doesn't have entitlements.
The error is the following:
{
"errors": [
{
"code": 20129,
"source": null,
"message": "User demo@vra.lab is not entitled to request 'Blueprint Name'.",
"systemMessage": "User demo@vra.lab is not entitled to request 'Blueprint Name''.",
"moreInfoUrl": null
}
]
}
A good vRA6 functionality is missing in vRA7. I understand that in vRA7 a machine is part of a Deployment. They forgot to include a new "Deployment.Admin.Owner" custom property.
Is the requesting account part of Business Group Manager?
Hi YestoVI, yes, it is.
I'd suggest using the subscriptions for now... you can set one up that looks at the value of that property and changes the owner if it doesn't match the current owner. I honestly never even knew setting that value had that effect. I always thought it was for adding the owner to a Windows systems local admin group. I have a feeling that might have actually been considered a bug or an undocumented feature.
What a nice and simple suggestion (I'm a little of embarrassed for not thinking about this myself)!!!
Thanks a lot, qc4vmware
Hi, I need a little help here because this is more difficult than I thought.
I've created a subscription on "Catalog item request completed" event and I've printed out all the info it sends:
taskType: PROVISION
subtenant: fcb8a0f5-a6cf-46b8-9d2f-585a57dff9f3
completionDetails:
requestId: b2166df6-7ad0-4849-9543-897a8530f2ca
success: true
deploymentId: efc7ba0b-b224-4870-b63f-7335442d9472
blueprintId: EmtpyBoxSVP
tenant: fibercorp
requestStatus: SUCCEEDED
And none of these ids helps me to find the Deployment to actually perform the "Change Owner". DeploymentId and RequestId are not the IDs I can see in the API.
Any tip?
Take a look at this thread. These are great starting points for using the subscriptions. vRA7 Event Broker Workflow Templates
Here is some code to return the catalog resource for the deployment. That is what you'll run the change owner on.
var hosts = some vCACCAFE:VCACHost
var resources = new Array();
var requestService = host.createCatalogClient().getCatalogConsumerRequestService();
var resources = requestService.getResourcesProvisionedByRequest(requestId,null).getContent();
//Loop through results
var vms = new Array();
var deployments = new Array();
for (var i = 0; i < resources.length; i++){
if (resources[i].resourceTypeRef.getLabel() === "Deployment") deployments.push(resources[i]);
if (resources[i].resourceTypeRef.getLabel() === "Virtual Machine") vms.push(resources[i]);
}
Finally I've sorted this out.
Unfortunately, it is very complex and couldn't done it using the vRA plugin for orchestrator, so I've used direct calls to the vRA API. But even then, the solution is tricky.
The IDs provided by the event broker (requestId and deploymentId) do not works with the API calls to get the Requests nor Deployments. Another problem is that the API call to get the deployments doesn't include the custom properties (needed to complete the action).
Finally, calling to the Action "Change Owner" is also tricky because the documentation is incomplete (and takes me a while to figure out how to build it).
So, if some one there needs to do something like this, let me know and I'll create a document with all the steps (many).
Bad news, guys.
I've unmarked the previous "Correct answer" because now that I have the subscription finished, I realize that doesn't work.
What I've seen is that by the time the event "Catalog item request completed" is triggered, the "Deployment Form" is not completed and doesn't have the custom properties available. So it is not possible to get the needed information to actually change the owner. Just after the Request is "Successful" the custom properties appears in the Deployment Form and this will not happens until the subscripted workflow finished the execution.
So, this is a dead end, at least for now.
I will keep trying to find the Custom Properties somewhere else, but for now, the only way to do this is:
. Manually, deploy the blueprint and then execute the Change Owner Action
. By API, execute the blueprint, wait until is Successful, and then call the API again to execute the Change Owner API.
A little update, the data sent by the subscription "Catalog item request completed" is the following:
taskType: PROVISION
subtenant: fcb8a0f5-a6cf-46b8-9d2f-585a57dff9f3
completionDetails:
requestId: 3873e726-74e9-4052-96d1-bf079f7e2c8d
success: true
deploymentId: d1ca808b-0ada-4c8c-b278-cb3c15eba125
blueprintId: BlueprintName
tenant:tenantName
requestStatus: SUCCEEDED
The best shot is to read the original Request, but the "requestId" sent by the subscription is not here:
/catalog-service/api/consumer/requests/
I guess it is from here:
/composition-service/api/requests/
but this service do not allow GET calls
So, dead end again.
Is there any way to get the data from the original request based on the "requestId" sent by the subscription "Catalog item request completed"?
Thanks a lot.
What we've had to do in the past is loop until the catalogResource is returned. Its not instant or at least my experience is it can take a while varying on how busy things are and overall performance of your deployment. I'm still very new to the subscriptions but I'm fairly certain if you are subscribed to a point in the lifecycle where the deployment has completed you should not have an issue changing the owner. You just might have to loop and retry a few times. Also, make sure your event subscription doesn't timeout too quickly.
Other ways you can achieve what you want to do are through a XaaS if you are licensed for it and use a workflow that does the deployment and a last step in that workflow is changing the owner.
You could also do an asynchronous workflow call from within your subscription that loops until all the assets needed seem to be available in the api. I've done this sort of thing many times in the past to deal with timing issues.
Nearly all of our deployments are done by a service account so they all need to have their owners flipped. We happen to use an XaaS blueprint as the launching point but are rapidly moving functions into the event subscriptions.
If I get a few minutes I'll try to put together a workflow package along with the subscription attributes necessary for it to work.
I can't really do the async call because this is an automated process and I need to know if something goes wrong. If I make the subscription "non blocking", I cannot raise an error if there is one. So, the only option is to do this with two different calls to the API (for now).
What I need right now is to get the original request, but the API doesn't allow GET calls to that service.
Thanks anyway, I'll keep looking.
We had these same requirements, and were able to meet them by using the Default error handler element in the workflow schema to send us an email if there is an issue with the asynch workflow called after the request has exited. We have deployed hundreds of VMs in this fashion, and have had less than five that we have had to step in and manually change the owner.