[Examples only] Updating random & null provider version constraint from 2.x to 3.x in the many terraform-aws-modules examples that use them

corzine commented 1 year ago

Terraform CLI and Provider Versions

Terraform v1.3.4 on darwin_arm64

provider registry.terraform.io/hashicorp/random (current is v3.4.3 but the versions in questions start at 2.0.0)
provider registry.terraform.io/hashicorp/null (current is v3.2.1 but the versions in questions start at 2.0.0)

Use Cases or Problem Statement

Summary

Update only those examples/*/versions.tf files in the terraform-aws-modules repos using random and null provider version constraints of 2.x to >= 3.0.0.

Details:

Many of the terraform-aws-modules used the random and/or null providers in their examples.
Most of these set their version constraints to something like >= 2.0.
At 3.0.0 the breaking changes for both random and null included going version 2 of the Terraform Plugin SDK (dropping support for 0.11).
Almost of all these use required_providers blocks, this was introduced in 0.13.
It is not clear if version 1 of the Terraform Plugin SDK is even supported in modern versions of Terraform. The current discussion is about going from SDKv2 to Terraform Plugin Framework. The SDKv1 that random & null v2.x depend on is clearly very old.
v 3.x also introduced support for linux-arm64 and darwin-arm64.
I have tentatively identified 57 versions.tf files in the examples/* directories which contain the random or null providers. It is possible I missed some as this was done by egrep -A2 'random|null' */examples/*/versions.tf in a directory with all of the modules cloned manually/individually.

Background

This came up when I used one of the examples from one of the terraform-aws-modules and copied the random provider's version constraint of >= 2.0. I then modified it to keep from going to the next major version w/o intervention by changing it to >= 2.0, < 3.0.0 (which I understand to be a recommended practice). terraform init then failed on my M1 Mac because no 2.x version supported it.

This was originally covered in #340 and @bendbennett asked for more information so it could be fixed. I realized I had already done the prep work and am volunteering to do the next steps.

Proposal

I am volunteering to prepare and submit all of the PRs to the various terraform-aws-modules that specify random & null provider v2.x. I have already done the prep work, cloned all of the (non-archived) modules belonging to the terraform-aws-modules organization, greped the examples and have a list of the files needing changes.

I am proposing to change all of these examples random & version v2.x version constraints to >= 3.0.0. No regular module code will be touched.

I will also look for uses of the random provider b64 attribute that was dropped in v3.0.0 and had been deprecated before that. This was the only other breaking change in either providers' CHANGELOG.md. (#118)

For testing I will perform a terraform init in each modified example (after removing any .terraform.lock.hcl files). This should test the scope of this change. I assume HashiCorp has more comprehensive testing in their CI pipelines.

Unless necessary, additional issues will not be created for this, only PRs which reference this issue.

Attached is a list of all identified files, results of a grep across them, and a copy of the task list below

A detailed task list of all of the files having the `random` or `null` providers (will be checked off as I submit the PRs)

End of the task list and proposal

How much impact is this issue causing?

Low

Additional Information

No response

Code of Conduct

[X] I agree to follow this project's Code of Conduct

corzine commented 1 year ago

Is my proposal appropriate or should this be left to HashiCorp employees?

This is my first attempt at contributing to Terraform and I've only tried to contribute to Open Source projects via Github a few times before. Have I done this correctly?

corzine commented 1 year ago

That list may look overwhelming but there are only 21 modules potentially affected (and some already use v3 of the providers). affected-files.txt

Module Task List

(end of list)

bendbennett commented 1 year ago

@corzine thank you for submitting a very thorough proposal.

The changes you are suggesting will need to be made on repositories that are maintained by the community.

It looks like the repositories you have listed are all associated with Terraform AWS modules.

I believe the PRs will need to be generated for each of the repositories in question. For instance the changes you are proposing for terraform-aws-s3-bucket will need to be raised as a PR for that repository.

corzine commented 1 year ago

Ok, thank you.

I didn't realize the Terraform AWS modules were community maintained, I thought they were "Official". That explains why they're in a different Github Organization.

bendbennett commented 1 year ago

@corzine Thank you for going to the trouble of identifying where the updates to the examples need to be made. I'm going to close this issue as the changes you are proposing are on repositories that are community maintained rather than HashiCorp maintained.

github-actions[bot] commented 5 months ago

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.

hashicorp / terraform-provider-random