-
Notifications
You must be signed in to change notification settings - Fork 33
Terraform returns "The resource cannot be found" when vRA deployment succeeds #32
Comments
I think part of the issue you'll run into with XaaS is that there isn't really an easy way to tell via the API what resources/deployments (if any) got spun up by the XaaS request. I've wondered if it's possible you could create a custom resource mapping and have your XaaS workflow return something that way but haven't had a chance to test that myself. |
Indeed, I was thinking about this too. But even with that, as Terraform bases its deployment check on the first workflow's ID (which contains nothing), I really doubt it would make any difference for Terraform to have another ID that has no meaning to it. |
Does this provider work at all with even a simple XaaS catalog item? I'm running into the same behavior with the "resource cannot be found" for a very simple vRO workflow. |
Sadly it seems It does not work for any vRO workflow. To confirm that I have intercepted requests going to vRA API. After posting new catalog item request it periodically checks for request/job status. Eventually I get status "SUCCESSFUL" for GET request on {
"@type": "CatalogItemRequest",
"id": "3db5bed3-2732-4d4b-8de9-b9b06463692e",
"iconId": "1179e777-4383-4ace-b50c-987e9ececd6a",
"version": 5,
"requestNumber": 7266,
"state": "SUCCESSFUL",
"description": "",
"reasons": "",
"requestedFor": "[email protected]",
"requestedBy": "[email protected]",
"organization": {
"tenantRef": "tenant1",
"tenantLabel": "tenant1",
"subtenantRef": "d252c0bc-489d-44e8-a430-343a49a35437",
"subtenantLabel": "admin"
},
"requestorEntitlementId": "a1d5e396-5e5e-47af-b44a-ed0e1db6f9d4",
"preApprovalId": null,
"postApprovalId": null,
"dateCreated": "2020-03-11T20:37:31.082Z",
"lastUpdated": "2020-03-11T20:38:55.100Z",
"dateSubmitted": "2020-03-11T20:37:31.082Z",
"dateApproved": null,
"dateCompleted": "2020-03-11T20:38:55.099Z",
"quote": {
"leasePeriod": null,
"leaseRate": null,
"totalLeaseCost": null
},
"requestCompletion": {
"requestCompletionState": "SUCCESSFUL",
"completionDetails": "The request was successfully completed",
"resourceBindingIds": null
},
"requestData": "SOME REAL DATA",
"retriesRemaining": 3,
"requestedItemName": "Users and Groups - Create BG",
"requestedItemDescription": "Create new Business Group",
"components": null,
"successful": true,
"final": true,
"stateName": "Successful",
"catalogItemRef": {
"id": "50879783-6c42-4f5e-942a-ab9365c92b3f",
"label": "Users and Groups - Create BG"
},
"catalogItemProviderBinding": {
"bindingId": "ioten!::!660c2c05-af90-4859-ab8e-fcdb79571d72",
"providerRef": {
"id": "818396ee-f4d7-4c62-bfc7-3c2384dc63ca",
"label": "XaaS"
}
},
"executionStatus": "STOPPED",
"waitingStatus": "NOT_WAITING",
"approvalStatus": "POST_APPROVED",
"phase": "SUCCESSFUL"
} Resource is actually created and can be verified in vRA portal. Then provider tries to read actual resources created using GET {
"links": [],
"content": [],
"metadata": {
"size": 20,
"totalElements": 0,
"totalPages": 0,
"number": 1,
"offset": 0
}
} It looks like only standard VMware resources like virtual machines are actually treated as resources in vRA API. This is crucial that we can also retrieve XaaS catalog items via standard resource API or some other endpoint so that it can be supported in terraform provider. @Prativa20 can you help us with that? Do you know anything about this issue or is there any way this can be fixed in near future? I could also create a PR if you'll provide me with more info or high level design of a preferred solution. |
@MaciejKaras We haven't tested XaaS blueprints from the provider. This will be a new requirement and we will prioritize this with other backlogs. I will update on this soon. |
What is the status on this? Soon < 1 year? |
What is the status and is there a workaround? |
What is the status of described issue? Any updates on it ? |
vRA 7.x version
7.5.0
Terraform version
0.12.7
terraform-provider-vra7 plugin version
0.4.1
Describe the bug
I tried to create Linux machines with a vRA XaaS.
This XaaS triggers a first workflow (with the ID "1"). It is used to instantiate resourceActions to create every needed resources for the machine.
It also instantiates another blueprint called "Linux" triggering a second workflow (with the ID "2") which aims to create the linux machine.
Terraform --> vRA XaaS blueprint --> 1st vRO workflow --> Linux blueprint --> 2nd vRO workflow
Terraform deployment is based on ID "1". When it ends, it makes the following API call to retrieve the machine's information:
GET https://{vra}/catalog-service/api/consumer/requests/{ID_1}/resourceViews
In my case, all the machine information are attached to ID "2", so at the end of the deployment, Terraform returns the error:
Expected behavior
Would it be possible to allow Terraform to get resources' information from another ID than the one given in the first place for the deployment?
The text was updated successfully, but these errors were encountered: