Provider does not recover from error

[waddles]

Nutanix Cluster Information

• AOS Version 5.10.9.1 LTS
• Prism Central Version 5.11.2.1 (but should apply to any)

Terraform Version

Terraform v0.12.23
+ provider.nutanix v1.0.2

Affected Resource(s)

• nutanix_virtual_machine

Terraform Configuration Files

See #130

Actual Behavior

Provider seems to always return the last failed task which triggers an error in Terraform.

Steps to Reproduce

1. Create a VM

   terraform apply -var atestvm -var disks='[
   {"label": "os", "sizeMb": 200}
   ]'

2. Increase the disk capacity like so:

   terraform apply -vars name=atestvm -var disks='[
   {"label": "os", "sizeMb": 215}
   ]'

3. Attempt to shrink the disk (expected to fail) like so:

   terraform apply -var atestvm -var disks='[
   {"label": "os", "sizeMb": 200}
   ]'

   which resulted in the expected error

   Error: error: {
     "message_list": [
       {
         "message": "error_code: 27\nerror_detail: \"NotSupported: Can\\'t shrink disk at scsi.0 of VM a9bce13b-a8a8-432f-80a9-0a716082abd0.\"",
         "reason": "INTERNAL_ERROR"
       }
     ],
     "state": "ERROR"
   }
   

Every operation after that results in the same error message from Terraform.

Important Factors

Nutanix API v3 does not support shrinking of disks. This issue is more about Terraform (and the Provider) not being able to recover from it.
​

References

• Provider prevents disk resizing at VM creation time #130

[waddles]

Turns out this is not actually a problem with Terraform or the provider, it is because the spec has gone into an ERROR state and the provider is correctly refusing to attempt any further operations.

The problem is in your Nutanix cluster, not the provider. Contact Nutanix Support to fix it.

The API is returning a status with "state": "ERROR" in the response and the above "message_list" object.

You can see the responses by running Terraform in debug mode:

TF_LOG=DEBUG terraform plan -var name=atestvm

If you run Community Edition and don't have a support contract, you can follow this procedure:

1. ssh to the PC VM
2. get a list of specs in ERROR state

   nuclei diag.get_specs state=kError spec_json=true

3. look for the spec that relates to your VM and delete that

   nuclei diag.delete_specs uuids={spec_uuid}

4. update the vm

   nuclei vm.update {vm_name}

[yannickstruyf3]

@waddles

This should be fixed in v1.1.0. Can you validate if this is also is the case for you?