search

vmware-archive / legacy-terraform-provider-vra7

Terraform provider for vRealize Automation 7
Mozilla Public License 2.0
60 stars 35 forks source link

catalog_name change detected if only catalog_id is used to deploy a resource on 2nd execution of tf apply #132

Open mponton opened 5 years ago

mponton commented 5 years ago

vRA 7.x version 7.4

Terraform version Terraform v0.11.11

terraform-provider-vra7 plugin version

119

Describe the bug I am using catalog_id to specify the blueprint to use in a deployment to work around #129 and noticed that if I apply against an already provisioned resource, I get the following:

  ~ module.linux_old_sat.vra7_resource.compute
      catalog_name:                                                    "BLUEPRINT_NAME" => ""

If I continue I get something like:

module.linux_old_sat.vra7_resource.compute: Modifying... (ID: a639d8a1-ed1d-4f87-8912-3411fb85bfa3)
  catalog_name: "BLUEPRINT_NAME" => ""
module.linux_old_sat.vra7_resource.compute: Still modifying... (ID: a639d8a1-ed1d-4f87-8912-3411fb85bfa3, 10s elapsed)
module.linux_old_sat.vra7_resource.compute: Still modifying... (ID: a639d8a1-ed1d-4f87-8912-3411fb85bfa3, 20s elapsed)
module.linux_old_sat.vra7_resource.compute: Still modifying... (ID: a639d8a1-ed1d-4f87-8912-3411fb85bfa3, 30s elapsed)
module.linux_old_sat.vra7_resource.compute: Modifications complete after 37s (ID: a639d8a1-ed1d-4f87-8912-3411fb85bfa3)

In the end, nothing is really changed but the same "change" will be detected and applied on the next run of terraform apply.

Since I specified the catalog_id I would expect the plugin to realize that catalog_name being empty is normal/acceptable.

I confirmed that having BOTH catalog_id and catalog_name set correctly will remove the "change" but curiously I also confirmed that if you have catalog_id set and catalog_name set to a name that does not correspond to said catalog_id, no change is detected (which is what I would expect as well when catalog_name is empty).

To Reproduce Steps to reproduce the behavior:

  1. Use ONLY catalog_id to specify which blueprint to deploy
  2. Deploy blueprint
  3. Run terraform apply again
  4. A catalog_name change is detected

Expected behavior catalog_id should have priority on catalog_name and when present, catalog_name should simply be ignored in any case.

NOTE: I would not consider this "issue" a priority. Simply letting you know of the unexpected behavior.

mponton commented 5 years ago

UPDATE: When I tested the above, I said:

I confirmed that having BOTH catalog_id and catalog_name set correctly will remove the "change" but curiously I also confirmed that if you have catalog_id set and catalog_name set to a name that does not correspond to said catalog_id, no change is detected (which is what I would expect as well when catalog_name is empty).

But I reported that WITHOUT running the apply. Actually having both fields is an issue when CREATING a resource since the catalog_name is looked up (and fails due to #129) but the catalog_id is ignored.

So in my case, having both fields will produce this error:

* vra7_resource.compute: Error in finding catalog item id corresponding to the catlog item name BLUEPRINT_NAME:
 <nil>

But having only catalog_id works for creation but produce unnecessary changes for existing resources if apply is run a second time.