Skip to content
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

Allow Variable to Control Provider Version #17211

Closed
stevegroner opened this issue Jan 26, 2018 · 5 comments
Closed

Allow Variable to Control Provider Version #17211

stevegroner opened this issue Jan 26, 2018 · 5 comments

Comments

@stevegroner
Copy link

Terraform Version

Version: 11.1

Affected Resource(s)

AWS Provider

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

# Create AWS Provider
provider "aws" {
  region = "${var.AWS_REGION}"
  version = "${var.PROVIDER_VERSION}"
}

Debug Output

N/A

Panic Output

N/A

Expected Behavior

The requested version of the provider be used. You should be able to centrally via variable define which provider version to pull. This will allow for me to modify when I want to update the provider to ensure compatibility before launching.

Actual Behavior

Successfully configured the backend "s3"! Terraform will automatically
use this backend unless the backend configuration changes.
Error getting plugins: provider.aws: invalid version constraint "${var.PROVIDER_VERSION}": Malformed constraint: ${var.PROVIDER_VERSION}

Steps to Reproduce

Create a provider using a variable in the version section

Important Factoids

N/A

References

N/A

@apparentlymart
Copy link
Member

Hi @stevegroner! Sorry this doesn't work as you expected.

Unfortunately this situation is as designed, because the providers need to be resolved at terraform init time, and thus they cannot dynamically change (as a result of re-assigning variables) after initialization.

The intent of the provider version constraints is to express what your module is compatible with, which is a property of the code itself rather than of its execution environment. So far we've recommended to either use an exact version or a ~> "pessimistic" constraint for each provider in your root module, and thus the root module centrally defines which providers are to be used for the entire configuration, including all descendant modules.

We're planning to improve this via #16835, which will allow child modules to express that they require particular provider versions without creating their own provider configurations. As described in that issue, we'd recommend that descendant modules use >= constraints to state their minimum compatible version while root modules would continue to use exact or ~> constraints to set the "top limit" on which version can be installed.

@dendrochronology
Copy link

Could someone please update the relevant docs to state why string interpolation isn't supported here? That would be a big help!

I don't see any mention of it here:

https://www.terraform.io/docs/configuration/providers.html#provider-versions

@aslafy-z
Copy link

aslafy-z commented Oct 8, 2021

This issue should be closed.

@bflad
Copy link
Member

bflad commented Oct 8, 2021

Thank you for the heads up, @aslafy-z! Indeed, it looks like this issue should be closed out, now that the terraform configuration block supports required_providers to set provider version constraints centrally per module, and the provider configuration block version argument has been explicitly deprecated in of Terraform CLI version 0.14 and later.

More information about specifying provider requirements (such as versioning) can be found in the Terraform configuration language documentation: https://www.terraform.io/docs/language/providers/requirements.html

@bflad bflad closed this as completed Oct 8, 2021
@github-actions
Copy link

github-actions bot commented Nov 8, 2021

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants