-
Notifications
You must be signed in to change notification settings - Fork 9.4k
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
terraform providers lock command don't honour the .terraformrc file #35106
Comments
Hi @carlitos081, Thanks for filing the issue. Does the resulting lock file work as expected when you specify the mirror using the |
Indeed, the original idea of this command was that it would intentionally ignore the provider installation configuration so that you can generate a dependency lock file containing the official release checksums and then use it to validate that your mirror was constructed correctly. This command is an "escape hatch" alternative because those who are using mirrors otherwise don't get the default behavior of The Although I don't think this is a bug (Terraform behaved as it was designed to behave), it does seem to me that it could be reasonable for this command to offer a shorthand option -- mutually-exclusive with the existing fs-mirror/net-mirror options -- that just means "use the same installation methods that |
I want to chime in on this issue since I looked into it in the past. It seems like not honoring Terraform CLI Config file is an explicit choice in the design of this particular command based on this comment: terraform/internal/command/providers_lock.go Lines 95 to 124 in bf0a6ed
Specifying the mirror URL explicitly using
Let's say I have a config that requires two providers: one can be installed from a filesystem mirror and the other one from a network mirror. Here is what I discovered about
After the last command, I will need to run The fact that the command needs to run several times (once for each installation method) and that providers need to be specified explicitly is super impractical. Adding proper support for Terraform CLI config similar to every other command would make things a lot easier. |
I don't intend the following as an argument for or against changing anything here. Just sharing some historical context about the design intent of these features, so that we can hopefully then talk about either ways in which the design assumptions were incorrect or how we could extend the functionality to support new use-cases that it wasn't originally intended for. The main thing to keep in mind about the current design is that the word "mirror" is meant to imply "exact copies of packages from the official source", and so the design is shaped by that assumption. The original intended user of filesystem or network mirrors has the following setup:
In this "happy path", the mirror naturally gets checked against the signed checksums that the developers fetched during their work. If the mirror has a missing or modified package then it will be detected by The This issue is implying a third situation that our mirror features were not designed to support: there are some provider packages that exist only in a mirror, and have no upstream origin registry and so therefore no "official" checksums (in the sense that Terraform thinks of "official", where the origin registry is the authority for its own namespace). In that case (as described in the comment above) the To make this work with today's Terraform, the provider packages would need to be published both in a provider registry and in the provider mirror, so that Terraform can verify that the mirror and the registry match. But if the mirror and the registry are both run by the same entity then that is essentially redundant: there is no separate "upstream authority" to check against. The idea I offered in my earlier comment would work for organisations that wish to use their mirror as the authoritative source for all providers, and perhaps that compromise is sufficient. A more general answer would be to allow some way to explicitly configure that a particular mirror is the authority for a specific set of providers and that there is not any upstream origin registry that the mirror is subordinate to. For example: provider_installation {
network_mirror {
url = "https://tf.example.com/providers/"
# This mirror is authoritative for
# any providers whose hostname
# is tf.example.com. There is no
# upstream registry to compare
# against.
authority_for = ["tf.example.com/*/*"]
# Since there is no include/exclude here
# Terraform will also prefer to use this
# mirror for installing any other providers
# too, but will treat their origin registries
# as authoritative for official checksums.
}
} In this hypothetical I'm imagining I don't know if this flexibility is actually needed. It might be sufficient to assume that if someone wants to treat their mirror as authoritative for anything then they want to treat it as the authority for everything, in which case I think my earlier idea of a new option on the lock command would be sufficient and considerably more straightforward. |
Terraform Version
my
.terraformrc
Debug Output
https://gist.github.com/carlitos081/1744aa46e0d73b56aa3e6c52a292bfbf
https://gist.github.com/carlitos081/8ea2d68ed52c4a4f08efa14e99946ef3
Expected Behavior
When I run
terraform init
I can see that the provider is downloaded from my network_mirrorhttps://artifactory.my-company.com/artifactory/api/terraform/terraform-virtual-dev/providers/
see the first gistWhen I run the
terraform providers lock -platform=linux_amd64
it will go directly tohttps://registry.terraform.io/v1/providers/hashicorp/aws/versions
instead of the mirror defined in.terraformrc
Actual Behavior
both
terraform init
andterraform providers lock -platform=linux_amd64
must honour the.terraformrc
Steps to Reproduce
.terraformrc
file as posted above and change to your own network_mirrorterraform init
you will see it is honouring the network_mirrorterraform providers lock -platform=linux_amd64
you will see it is to the public mirrorhttps://registry.terraform.io/
insteadAdditional Context
No response
References
No response
The text was updated successfully, but these errors were encountered: