Update ha_datastore_apd_response_delay defaults and docs

[tenthirtyam]

Description

• Updates ha_datastore_apd_response_delay to the API default for vmTerminateDelayForAPDSec.
• Updates the compute_cluster resource documentation to seconds versus minutes for ha_datastore_apd_response_delay.
• Updates the compute_cluster resource documentation to use the same structure for describing time-based arguments .

Release Note

Release note for CHANGELOG:

Updates `ha_datastore_apd_response_delay` in the `compute_cluster` resource to the API default (180) for `vmTerminateDelayForAPDSec`.

References

• Closes: ha_datastore_apd_response_delay units issue #1438
• Closes: Documentation for vsphere_compute_cluster ha_datastore_apd_response_delay incorrect #1386
• API: vmTerminateDelayForAPDSec

[appilon]

Normally changing defaults typically could be interpreted as a breaking change if it significantly changes the behavior of the system, but considering we are adjusting a delay, and it appears the old value was erroneously calculated in minutes when the code uses it as seconds, this change is fine, just update the description on in the Go code.

Maybe one day we will generate the docs from the descriptions so they don't need to be double maintained... sigh

[appilon]

Actually... might have to do a state migration to make this non-breaking... ugh. I need a refresher on the nuance of state here, let me created an isolated example and get back to you.

[tenthirtyam]

Thanks for taking a look into this one, I've committed your changes in the review.

I didn't think about the possible impact to state changes.😬

Ryan

[appilon]

In practical terms this should be an easy change, but the fact that all attributes are committed to state it could cause a bad user experience/diff for the users, might be able to migrate their state from 3 to 180 if their config was left empty (implying they were relying on the default). The problem is the old SDK (which this provider uses) doesn't do a good job of providing config vs state...

[tenthirtyam]

I suppose the changes in GH-1460 for the TF SDK don't help with that concern?

[appilon]

Unfortunately no the new SDK I refer to is this one https://github.com/hashicorp/terraform-plugin-framework. And it won't be feasible to migrate to it for this provider, not to get sidetracked. Lemme see what I can repro in an isolated example.

[appilon]

Okay so I ran a few scenarios in an isolated environment.

1. In the case where state is 180 but the default of 3 causes a diff (as described in ha_datastore_apd_response_delay units issue #1438) the change in this PR fixes the situation completely. It's odd though, I traced the code and I would NOT expect this to be the scenario must users are in, a default of 3 should have been sent to the API, Create/Update call Read to sync state, where I would expect 3 to be read back (not 180).

2. This is the case that I expect to see, where 3 is currently in state, if we switch the default to 180, then the user will be prompted with a state drift.

Note: Objects have changed outside of Terraform

Terraform detected the following changes made outside of Terraform since the last "terraform apply":

  # bug_example.test has changed
  ~ resource "bug_example" "test" {
        id    = "example"
      ~ thing = 3 -> 180
    }

If the user applies, then there are no subsequent messages/problems.

Given that, I think it's safe to merge this PR without any state migrations, we will make note in the changelog that a onetime drift message is possible. I did notice there is another piece of schema that I guess mirrors this one but for overrides?

@tenthirtyam Can you perform the doc updates here and here as well?

[tenthirtyam]

@appilon I'll make these needed changes and update the PR very soon. Thanks!

Ryan

[tenthirtyam]

Committed the changes for the ha_datastore_apd_response_delay to denote the time interval from minutes to seconds.

[tenthirtyam]

Thanks for the support @appilon!

[github-actions]

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.