-
Notifications
You must be signed in to change notification settings - Fork 118
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
[Examples only] Updating random & null provider version constraint from 2.x to 3.x in the many terraform-aws-modules examples that use them #342
Comments
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? |
That list may look overwhelming but there are only 21 modules potentially affected (and some already use v3 of the providers). Module Task List
(end of list) |
@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. |
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. |
@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. |
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. |
Terraform CLI and Provider Versions
Terraform v1.3.4
on darwin_arm64
Use Cases or Problem Statement
Summary
Update only those
examples/*/versions.tf
files in the terraform-aws-modules repos usingrandom
andnull
provider version constraints of 2.x to>= 3.0.0
.Details:
>= 2.0
.random
andnull
included going version 2 of the Terraform Plugin SDK (dropping support for 0.11).required_providers
blocks, this was introduced in 0.13.linux-arm64
anddarwin-arm64
.versions.tf
files in theexamples/*
directories which contain therandom
ornull
providers. It is possible I missed some as this was done byegrep -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
providerb64
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
ornull
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
The text was updated successfully, but these errors were encountered: