terraform-provider-vra7
terraform-provider-vra7 copied to clipboard
vmware
Update the VM state (ie: power on/power off)
vRA 7.x version vRA 7.3 Terraform version Terraform v0.12.26
terraform-provider-vra7 plugin version provider.vra7 v1.0.1
Describe the bug Can't change state of the VM instances provisioned by Terraform through vRA.
Context I build a VM through vRA using a terraform plan and the vRA7 provider successfully. If I try to change the lease that's goes through without a problem, same if I change CPU or Mem. I can't start a VM (that was powered off through vRA) by running a terraform updated plan.
Further details If I shutdown the VM from vRA or vCenter, upon a state refresh the respective details are properly updated in the state file, so one can see its status and available actions per that status, for example: Right after provisioing the VM through terraform (the VM is on), I have:
"PowerOff": "true", "Reboot": "true", "Reconfigure": "true", "Reprovision": "true", "Reset": "true", "Shutdown": "true", "Suspend": "true", "status": ""
Whilst, after I've run shutdown (from vc or vra) following a terraform refresh I now have:
"PowerOn": "true", "Reconfigure": "true", "Reprovision": "true", "status": "Off"
If I power the VM on from vRA, then I have:
"PowerOff": "true", "Reboot": "true", "Reconfigure": "true", "Reprovision": "true", "Reset": "true", "Shutdown": "true", "Suspend": "true", "status": "on"
So, following this observation (while the VM was still poweroff) I've updated the main terraform plan by changing the state, once that hasn't worked, I've tried changing some of the other, like setting PowerOff=true (have had quite a few tries and combinations). All terraform plans get applied successfully and in vRA under Requests tab I can see the "Reconfigure a machine" action that terraform instigates, finishing successfully as well. The VM on the other hand, doesn't power on, or power off to that matter.
Conclusion As mentioned, this may not be a bug, but I would have expected I can modify any of the resource properties after the initial provisioning. In case this is not a bug, an explanation as to how it all works would be highly appreciated.
To Reproduce Steps to reproduce the behavior:
- The VM is already provisioned through terraform and I'm reapplying the following plan:
provider "vra7" { username = var.vrauser password = var.vrapass tenant = var.vratenant host = var.vrahost insecure = true }
resource "vra7_deployment" "TFTest01" { count = 1 catalog_item_name = "RHEL7.6" description = "test terraform deployment" lease_days = 20 businessgroup_name = "icds_bg"
resource_configuration { component_name = "vSphere_Machine_1" configuration = { cpu = 2 memory = 2234 custom_property = "Terraform custom property test" Status = "On" } } }
- Terraform command
terraform plan
2020/06/19 10:36:41 [WARN] Log levels other than TRACE are currently unreliable, and are supported only for backward compatibility. Use TF_LOG=TRACE to see Terraform's internal logs.
Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage.
vra7_deployment.TFTest01[0]: Refreshing state... [id=46610d78-efa8-43f5-a840-3fb42e2335a5]
An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: ~ update in-place
Terraform will perform the following actions:
vra7_deployment.TFTest01[0] will be updated in-place ~ resource "vra7_deployment" "TFTest01" { businessgroup_id = "6e21cee9-126e-4c8a-b532-b97d6778739b" businessgroup_name = "icds_bg" catalog_item_id = "8db0471f-44fd-4595-a600-8399627f7b77" catalog_item_name = "RHEL7.6" date_created = "2020-06-18T21:08:48.204Z" deployment_destroy = true deployment_id = "3528b5af-07cd-4efc-976a-4b9a3afe226e" description = "test terraform deployment" id = "46610d78-efa8-43f5-a840-3fb42e2335a5" last_updated = "2020-06-19T07:13:48.517Z" lease_days = 20 lease_end = "2020-07-09T10:13:24.300Z" lease_start = "2020-06-18T21:08:48.190Z" name = "RHEL7.6-81936314" owners = [ "octavian.teodorescu", ] request_status = "FAILED" tenant_id = "ICDS" wait_timeout = 15
- resource_configuration { - cluster = 1 -> null - component_name = "vSphere_Machine_1" -> null - configuration = { - "CancelReconfigure" = "true" - "Component" = "vSphere_Machine_1" - "DISK_VOLUMES.0.DISK_CAPACITY" = "20" - "DISK_VOLUMES.0.DISK_INPUT_ID" = "DISK_INPUT_ID1" - "DISK_VOLUMES.0.DISK_LABEL" = "Hard disk 1" - "EXTERNAL_REFERENCE_ID" = "vm-882" - "ExecuteReconfigure" = "true" - "GetExpirationReminder" = "true" - "IS_COMPONENT_MACHINE" = "false" - "MachineBlueprintName" = "RHEL7.6" - "MachineDailyCost" = "0" - "MachineDestructionDate" = "2020-07-09T10:13:24.000Z" - "MachineExpirationDate" = "2020-07-09T10:13:24.000Z" - "MachineGroupName" = "icds_bg" - "MachineGuestOperatingSystem" = "Red Hat Enterprise Linux 7 (64-bit)" - "MachineInterfaceDisplayName" = "vSphere (vCenter)" - "MachineInterfaceType" = "vSphere" - "MachineReservationName" = "ansible-reservation" - "NETWORK_LIST.0.NETWORK_ADDRESS" = "xx.xxx.9.12" - "NETWORK_LIST.0.NETWORK_MAC_ADDRESS" = "00:50:56:be:78:df" - "NETWORK_LIST.0.NETWORK_NAME" = "DPortGroup" - "NETWORK_LIST.0.NETWORK_NETWORK_NAME" = "SLNetwork192" - "NETWORK_LIST.0.NETWORK_PROFILE" = "SL Network 192" - "VirtualMachine.Admin.UUID" = "503e5bb7-d639-8cb7-790e-52e176e43660" - "cpu" = "2" - "endpointExternalReferenceId" = "f65a17da-87ef-4350-a9ec-8c19ebff3790" - "ip_address" = "xx.xxx.9.12" - "machineId" = "e8d0b355-ffd5-4f06-9c5b-ecf9c64951d5" - "memory" = "2234" - "name" = "AZ0022" - "storage" = "20" - "type" = "Virtual" } -> null - date_created = "2020-06-18T21:15:38.697Z" -> null - ip_address = "xx.xxx.9.12" -> null - last_updated = "2020-06-19T07:13:52.109Z" -> null - name = "AZ0022" -> null - parent_resource_id = "3528b5af-07cd-4efc-976a-4b9a3afe226e" -> null - request_id = "46610d78-efa8-43f5-a840-3fb42e2335a5" -> null - request_state = "SUCCESSFUL" -> null - resource_id = "9fb7ca4f-4307-40e3-9dbb-d74ac25bf213" -> null - resource_type = "Infrastructure.Virtual" -> null - status = "Off (Reconfigure failed, waiting to retry)" -> null } + resource_configuration { + cluster = (known after apply) + component_name = "vSphere_Machine_1" + configuration = { + "Status" = "On" + "cpu" = "2" + "custom_property" = "Terraform custom property test" + "memory" = "2560" } + date_created = (known after apply) + description = (known after apply) + ip_address = (known after apply) + last_updated = (known after apply) + name = (known after apply) + parent_resource_id = (known after apply) + request_id = (known after apply) + request_state = (known after apply) + resource_id = (known after apply) + resource_type = (known after apply) + status = (known after apply) } }Plan: 0 to add, 1 to change, 0 to destroy.
Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.
Then I run apply:
terraform apply -auto-approve 2020/06/19 10:38:05 [WARN] Log levels other than TRACE are currently unreliable, and are supported only for backward compatibility. Use TF_LOG=TRACE to see Terraform's internal logs.
vra7_deployment.TFTest01[0]: Refreshing state... [id=46610d78-efa8-43f5-a840-3fb42e2335a5] vra7_deployment.TFTest01[0]: Modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 10s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 20s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 30s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 40s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 50s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m0s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m10s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m20s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m30s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m40s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 1m50s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 2m0s elapsed] vra7_deployment.TFTest01[0]: Still modifying... [id=46610d78-efa8-43f5-a840-3fb42e2335a5, 2m10s elapsed] vra7_deployment.TFTest01[0]: Modifications complete after 2m17s [id=46610d78-efa8-43f5-a840-3fb42e2335a5]
Apply complete! Resources: 0 added, 1 changed, 0 destroyed.
- Error No error, but the VM Machine state does not change, the state looks like this:
{ "version": 4, "terraform_version": "0.12.26", "serial": 16, "lineage": "0062d5d7-6b32-b911-998e-47d45c63a129", "outputs": {}, "resources": [ { "mode": "managed", "type": "vra7_deployment", "name": "TFTest01", "each": "list", "provider": "provider.vra7", "instances": [ { "index_key": 0, "schema_version": 0, "attributes": { "businessgroup_id": "6e21cee9-126e-4c8a-b532-b97d6778739b", "businessgroup_name": "icds_bg", "catalog_item_id": "8db0471f-44fd-4595-a600-8399627f7b77", "catalog_item_name": "RHEL7.6", "date_created": "2020-06-18T21:08:48.204Z", "deployment_configuration": null, "deployment_destroy": true, "deployment_id": "3528b5af-07cd-4efc-976a-4b9a3afe226e", "description": "test terraform deployment", "id": "46610d78-efa8-43f5-a840-3fb42e2335a5", "last_updated": "2020-06-19T07:13:48.517Z", "lease_days": 20, "lease_end": "2020-07-09T10:13:24.300Z", "lease_start": "2020-06-18T21:08:48.190Z", "name": "RHEL7.6-81936314", "owners": [ "octavian.teodorescu" ], "reasons": null, "request_status": "SUCCESSFUL", "resource_configuration": [ { "cluster": 1, "component_name": "vSphere_Machine_1", "configuration": { "ChangeLease": "true", "ChangeOwner": "true", "Component": "vSphere_Machine_1", "CreateSnapshot": "true", "DISK_VOLUMES.0.DISK_CAPACITY": "20", "DISK_VOLUMES.0.DISK_INPUT_ID": "DISK_INPUT_ID1", "DISK_VOLUMES.0.DISK_LABEL": "Hard disk 1", "Destroy": "true", "EXTERNAL_REFERENCE_ID": "vm-882", "Expire": "true", "GetExpirationReminder": "true", "IS_COMPONENT_MACHINE": "false", "MachineBlueprintName": "RHEL7.6", "MachineDailyCost": "0", "MachineDestructionDate": "2020-07-09T10:13:24.000Z", "MachineExpirationDate": "2020-07-09T10:13:24.000Z", "MachineGroupName": "icds_bg", "MachineGuestOperatingSystem": "Red Hat Enterprise Linux 7 (64-bit)", "MachineInterfaceDisplayName": "vSphere (vCenter)", "MachineInterfaceType": "vSphere", "MachineReservationName": "ansible-reservation", "NETWORK_LIST.0.NETWORK_ADDRESS": "xx.xxx.9.12", "NETWORK_LIST.0.NETWORK_MAC_ADDRESS": "00:50:56:be:78:df", "NETWORK_LIST.0.NETWORK_NAME": "DPortGroup", "NETWORK_LIST.0.NETWORK_NETWORK_NAME": "SLNetwork192", "NETWORK_LIST.0.NETWORK_PROFILE": "SL Network 192", "PowerOn": "true", "Reconfigure": "true", "Reprovision": "true", "VirtualMachine.Admin.UUID": "503e5bb7-d639-8cb7-790e-52e176e43660", "cpu": "2", "endpointExternalReferenceId": "f65a17da-87ef-4350-a9ec-8c19ebff3790", "ip_address": "xx.xxx.9.12", "machineId": "e8d0b355-ffd5-4f06-9c5b-ecf9c64951d5", "memory": "2560", "name": "AZ0022", "storage": "20", "type": "Virtual" }, "date_created": "2020-06-18T21:15:38.697Z", "description": "", "ip_address": "xx.xxx.9.12", "last_updated": "2020-06-19T07:13:52.109Z", "name": "AZ0022", "parent_resource_id": "3528b5af-07cd-4efc-976a-4b9a3afe226e", "request_id": "46610d78-efa8-43f5-a840-3fb42e2335a5", "request_state": "SUCCESSFUL", "resource_id": "9fb7ca4f-4307-40e3-9dbb-d74ac25bf213", "resource_type": "Infrastructure.Virtual", "status": "Off" } ], "tenant_id": "ICDS", "wait_timeout": 15 }, "private": "xxxxxx==" } ] } ] }
Expected behavior Would have expected that when I have changed the State (or any of the other reboot variables) to apply these changes to the existing instance. On the other hand, the command terraform plan, does sort allude that's not something I am controlling, ie:
- date_created = "2020-06-18T21:15:38.697Z" -> null - ip_address = "xx.xxx.9.12" -> null - last_updated = "2020-06-18T21:37:50.320Z" -> null - name = "AZ0022" -> null - parent_resource_id = "3528b5af-07cd-4efc-976a-4b9a3afe226e" -> null - request_id = "46610d78-efa8-43f5-a840-3fb42e2335a5" -> null - request_state = "SUCCESSFUL" -> null - resource_id = "9fb7ca4f-4307-40e3-9dbb-d74ac25bf213" -> null - resource_type = "Infrastructure.Virtual" -> null - status = "Off" -> null } + resource_configuration { + cluster = (known after apply) + component_name = "vSphere_Machine_1" + configuration = { + "PowerOff" = "true" + "PowerOn" = "false" + "Status" = "On" + "cpu" = "2" + "custom_property" = "Terraform custom property test" + "memory" = "2234" } + date_created = (known after apply) + description = (known after apply) + ip_address = (known after apply) + last_updated = (known after apply) + name = (known after apply) + parent_resource_id = (known after apply) + request_id = (known after apply) + request_state = (known after apply) + resource_id = (known after apply) + resource_type = (known after apply) **+ status = (known after apply)** } }Plan: 0 to add, 1 to change, 0 to destroy.
Screenshots
Screenshot of the vRA reconfigure operation:
Logs 19062020-102137.log
Desktop (please complete the following information):
- OS: Running the terraform commands on mac os (10.15.5), using vscode to edit files and github to store.
