AWS provider >=4.0.0 requirement causes incompatibilities with other popular modules

[r2bit]

The hashicorp/aws provider version 4.0 and above introduced quite a bit of incompatibility problems.

Some examples:

• terraform-aws-s3-bucket - Support terraform-provider-aws 4.x terraform-aws-modules/terraform-aws-s3-bucket#137
• terraform-provider-aws RDS - resource/aws_db_instance: Correctly handles update and reboot for replica instances hashicorp/terraform-provider-aws#22178 (comment)

These are just few issues we are encountering with 4.0.0.
Seeing as how 3.74.x is still being maintained (most recent minor from 5 days ago), maybe it is possible to lower the requirement of this particular module to >=3.74.3? Unless, of course, the module or Sysdig provider itself already depend on some 4.0+ specifics.

[wideawakening]

there are no specific requirements we needed from 4.0.0, but we would like to be as near to the latest version as possible.
because we use >= semver CI failed due to the breaking changes, an thus, we upgraded.

saw there is a workaround to avoid default provider to be determined by the maximum version of modules that you disliked.
have not tried it, let us give it a thought to this.

ha..

[r2bit]

saw there is a workaround to avoid default provider to be determined by the maximum version of modules that you disliked. have not tried it, let us give it a thought to this.

Indeed. I disliked it because that's not designed to work as per this thread. :P
But I will go ahead and give it a try...

[wideawakening]

hum, yep, that explanation about cross-module provider makes sense.

going to the official docs
https://www.terraform.io/language/modules/develop/providers#provider-version-constraints-in-modules

Although provider configurations are shared between modules, each module must declare its own, so that Terraform can ensure that there is a single version of the provider that is compatible with all modules in the configuration and to specify the source address that serves as the global (module-agnostic) identifier for a provider.

indeed one version per provider source is selected and chosen in the .terraform.lock.hcl file, matching the constraints

provider "registry.terraform.io/hashicorp/aws" {
  version     = "4.2.0"
  constraints = ">= 3.50.0, >= 3.62.0, >= 3.63.0, >= 4.0.0"

and a constraint like ~> 3.69, >= 4.0.0 cannot match

[r2bit]

@wideawakening would it help if I created a commit/PR for this change? Or you rather not lower the constraint anymore?

[wideawakening]

we rather not lower the constraint and push forward, but depends on our client's requirements too. have not had much feedback related to this topic.

anyhow, is the aws/s3 module the only thing that's blocking you right now? if so, think it's worth to wait.
anton is dealing with ukraine situation 🇺🇦 💪🏽 , but still working on a draft and many other users are working on it too

[r2bit]

anyhow, is the aws/s3 module the only thing that's blocking you right now? if so, think it's worth to wait.

Yes, unless we completely isolate Sysdig modules. But I completely understand that stance of not downgrading version requirements.

I think we may close this issue.

🇺🇦 💪🏽

[antonbabenko]

Hi guys!

terraform-aws-modules/terraform-aws-s3-bucket#139 is almost ready to be released. I need to verify one example for S3 replication, so if you have time (today or tomorrow) and the possibility, please give that PR a try:

module "s3" {
  source = "git::https://github.com/terraform-aws-modules/terraform-aws-s3-bucket.git?ref=fix-tf-provider-v4"
}

There is an upgrade guide - https://github.com/terraform-aws-modules/terraform-aws-s3-bucket/blob/fix-tf-provider-v4/UPGRADE-3.0.md