vmware / terraform-provider-vra7

Terraform VMware vRealize Automation 7 provider - VMware has ended the active development of this Terraform Provider, so this repository will no longer be updated.
https://registry.terraform.io/providers/vmware/vra7/latest
Mozilla Public License 2.0
39 stars 33 forks source link

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

Open aleost1 opened 5 years ago

aleost1 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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": "tenant1user@vsphere.local",
  "requestedBy": "tenant1user@vsphere.local",
  "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 commented 4 years ago

@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 commented 3 years ago

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

RobMokkink commented 3 years ago

What is the status and is there a workaround?

aindenko commented 3 years ago

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