Merge new dependency handling from terraform core

[magodo]

There are some dependency issues are fixed in hashicorp/terraform#23252, while this currently seems not merged into SDK yet. Is there any chance to get it merged so that provider code do not need to introduce workaround for the dependency bugs.

References

• store absolute addresses for resource dependencies in the state terraform#23252

[paultyng]

The binary testing driver eliminates the need to update TF core logic in the acceptance testing framework in this SDK. v2 eliminates the in process TF approximation entirely to avoid issues like this where the SDK or included version of Terraform drifts from the CLI code. It would be better to work towards using the binary testing driver instead and then you can invoke whatever version of Terraform core you want for testing.

[magodo]

@paultyng Thank you for the quick reply! I'm not sure what does "binary testing driver" means? The dependency issues addressed by that PR still exist in other providers (e.g. azurerm), no matter you are using terraform from CLI or running via acceptance test (even with latest SDK version).

[paultyng]

@magodo yeah, sorry I wasn't clear, the documentation is trailing a little here, but I queued up some issues to address it this week. Here is the PR for the original binary test driver: #262 and here is a PR I just created to add some preliminary package docs: #385

The goal with this test driver is to remove all of the "emulation" for Terraform CLI from the SDK testing packages and completely separate this repo from the core repo at a dependency level. This also ensures our testing is much more representative of the real world (we discovered some instances where tests returned false positives that failed in a CLI around importing, for example).

Its backwards compatible, so you don't need to change your test code (although you need to add some code to a TestMain), but instead of using the in module copy of Terraform core code, it:

1. optionally downloads a Terraform binary (or uses one on path)
2. writes the test step configs out to a temporary dir
3. runs plan/apply/import, etc, with the binary, reading state back in as JSON for your checks

So this completely decouples the new acc testing framework from the CLI repo for test running, which means we no longer need to sync these packages (as they are only used during testing here, not during provider runtime). But it can also enable some nice things, like running with pre-release TF versions or a matrix test against TF versions, etc. We plan to hopefully use it to test state migrations and other things over time.

I do see one line of code in here that is reproduced in our shims, but not sure if it matters or not, I will dig in to it with the core team just to clarify: https://github.com/hashicorp/terraform/pull/23252/files#diff-4964cd37aa1c7c8e29a787ee55b086de

[paultyng]

While this framework is opt-in, we do still maintain duplicates of this core code of course, but in v2 (currently in dev on the version2 branch), it is no longer optional and instead mandatory, as v2 drops all the code dependencies. So while it does look like this code is present in other providers, as they switch to the binary testing driver, its no longer executed.

[magodo]

@paultyng Thank you so much for the context clarification!
So does it mean the only reason of terraform directory exists in SDK is to support acctest?

[paultyng]

Yes, correct, the majority of the Terraform core code that is replicated here is solely to run acceptance testing.

[magodo]

Thank you for explaining the details 👏
Close it now.

[ghost]

I'm going to lock this issue 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 similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.