Skip to content
This repository has been archived by the owner on Jun 17, 2024. It is now read-only.

Terraform returns "The resource cannot be found" when vRA deployment succeeds #32

Open
aleost1 opened this issue Oct 8, 2019 · 8 comments

Comments

@aleost1
Copy link

aleost1 commented Oct 8, 2019

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:

Error: The resource cannot be found

  on main.tf line 8, in resource "vra7_deployment" "Test-VM":
   8: resource "vra7_deployment" "Test-VM" {

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?

@cars
Copy link
Contributor

cars commented Oct 9, 2019

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.

@aleost1
Copy link
Author

aleost1 commented Oct 10, 2019

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.

@pezhore
Copy link

pezhore commented Nov 19, 2019

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.

@MaciejKaras
Copy link
Contributor

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 /catalog-service/api/consumer/requests/3db5bed3-2732-4d4b-8de9-b9b06463692e:

{
  "@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 /catalog-service/api/consumer/requests/3db5bed3-2732-4d4b-8de9-b9b06463692e/resourceViews but gets nothing:

{
  "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.

@Prativa20
Copy link
Contributor

@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.

@bbaassssiiee
Copy link

What is the status on this? Soon < 1 year?

@RobMokkink
Copy link

What is the status and is there a workaround?

@aindenko
Copy link

aindenko commented May 6, 2021

What is the status of described issue? Any updates on it ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants