Getting provisioned resources for a XaaS blueprint through API

[koyadume]

I have a XaaS blueprint where workflow for this blueprint triggers a requsest for iaas blueprint. This creates two requests in vRA - one for xaas blueprint and another for iaas blueprint. Using request id for iaas blueprint, I can get details of resources provisioned by this blueprint using catalog-service/api/consumer/resourceViews/<request_id> api call. Problem is that I have request id of xaas blueprint only as my code triggers a request for xaas blueprint. If I pass xaas request id in catalog-service/api/consumer/resourceViews/<request_id> api call, it does not return details of all provisioned resources (deployments, VMs etc). I thought of supplying xaas request id in iaas blueprint request template and then quering all the requests by xaas request id but don't see a way to achieve this. How can I get the details of all the provisioned resources for this scenario?

[Hejahida82]

In your XaaS request vRO workflow set an output parameter named for example iaasRequestId and of type String.

Add a scripting element into the XaaS workflow and use it to set the value of the iaasRequestId parameter to the value of the IaaS request submitted to vRA, you can get this using getId method on the catalog request object created when you submit the request in the XaaS workflow.

When you want to retrieve the details of the provisioned resources you can perform a GET on the XaaS request details to /catalog-service/api/consumer/requests/forms/details. The results of the API call will include an entry for the output parameter you have in the XaaS workflow iaasRequestId with its value being the IaaS request id the VMs are provisioned under. You can now query the IaaS request id for any XaaS request and get the provisioned resources in the same way you would if you had just submitted an IaaS request.

[koyadume]

This is the solution which I am already using currently. But I feel this is a hack/workaround instead of being an elegant solution. There should be a way to pass xaas reqeust id in all the composite blueprints requests triggered by xaas blueprints and then it should be possible to get all the provisioned resources using catalog-service/api/consumer/resources api call where one should be able xaas request id as query parameter.

Considering that this is a very common use case, looking for some better solution.

[Hejahida82]

I'd loved to be proved wrong but I don't believe there is any other way to do what you are looking for. From my experience there is no relationship between the XaaS and IaaS requests other than when you get the IaaS request in the way you are using today. The XaaS request is effectively just simulating a user clicking the buttons in the vRA gui to submit a request, the IaaS request has no knowledge of the fact it wasn't actually a user but was an XaaS request that submitted it. All the request related values in the event broker payload point to the IaaS request and the provisioned resources will always belong to the IaaS request and not the XaaS request. So I believe you will always need to perform the two hop method to retrieve the provisioned resources.

[koyadume]

Tags is a common feature which are provided by almost all the public/private clouds when it comes to a resource. This will allow to attach any custom data to a resource. This IMO is perfect solution.

But then I am not sure if this is possible. I was searching for it in vRA API documentation when I started working on this problem but could not find anything.

Another solution which I can think of is creating a hidden property in iaas blueprint for storing xaas request id and then searching deployments by this hidden property. Again I am not sure if this is possible.

Your thoughts?

[Hejahida82]

vRA will allow you to use tags on the provisioned resources but doesn't provide a structure you could use to query them as far as I am aware as each cloud/IaaS endpoint has a different type of tag.

Custom property on the IaaS blueprint is a good idea but I think you would need to stamp this into the request data within the XaaS workflow, so that it is on the VMs/deployments when they are requested within the XaaS workflow. I'm not sure you can get access to the XaaS request id within the XaaS workflow while it is still in progress, although I haven't tried it recently. After that all event broker subscriptions will be based off of the IaaS request so you wouldn't have access to the XaaS request id.

I experimented with approval policies to see if that would give an option, approval policy which auto approves via a vRO workflow and set on the XaaS catalog request, but I didn't find anyway to get a link between the XaaS and IaaS requests.

It seems like such a simple thing to want to do, it's really frustrating that there doesn't seem to be an elegent solution to it.