-
Notifications
You must be signed in to change notification settings - Fork 452
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: disk provisioning settings are not correctly applied #2028
fix: disk provisioning settings are not correctly applied #2028
Conversation
e56e5e4
to
cdde530
Compare
Fixes hashicorp#1028 1) According to the issue eagerly_scrubbed and thin_provision are not applied correctly when set and the providers is throwing an error. It is nomrmal VM disk to receive values different from the ones in the configuration - it depends entirely on the vSphere backend. In such cases the provider should not throw an error. See https://kb.vmware.com/s/article/2145183 - removed the validation regarding both fields so ignore_state fixes the deployment 2) In another comment of the issue it is stated that when VM is cloned with different values for eagerly_scrubbed and thin_provision from the ones of the original disk the values are not applied (tested on VMFS datastore). - initialy the provider stated that if there is no datastore explicitly set for the disk no relocation changes will be sent to the api for this disk. This is changed to making a diff between the disk properties specified in HCL and the same on the exisiting disk on the source VM Added e2e test to cover both cases. Fixed unit tests broken by Bumps [github.com/vmware/govmomi](https://github.com/vmware/govmomi) from 0.30.7 to 0.31.0. hashicorp@37f0a77 Signed-off-by: Vasil Atanasov <[email protected]>
cdde530
to
88b62f9
Compare
Updates `CHANGELOG.md`. Signed-off-by: Ryan Johnson <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
This functionality has been released in v2.5.0 of the Terraform Provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you! |
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Description
Fixes #1028
eagerly_scrubbed
andthin_provision
are not applied correctly when set and the providers is throwing an error. It is normal for the VM disk to receive values different from the ones in the configuration - it depends entirely on the vSphere datastore backend. In such cases, the provider should not throw an error. See VMware KB 2145183.ignore_state
fixes the deployment.eagerly_scrubbed
andthin_provision
from the ones of the original disk the values are not applied (tested on VMFS datastore).Added e2e test to cover both cases.
Acceptance tests
Output from acceptance testing.
Failed tests run separately because of the environment when all tests are executed.
Failing on localy and on acceptance.
Release Note
r/vsphere_virtual_machine
: Disk changes sent in relocate spec when the VM is cloned do not depend so solely on presence of datastore id in disk configuration in HCL. The need to send the disk spec is calculated based on attribute differences on the existing disk for following attributes:Still the
thin_provisioned
andeagerly_scrub
properties depend mostly on the storage backend, so it is not guaranteed that ones provided in the config will be applied. the following workaround will do the job.References
#1028