-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
init
fails for development overrides
#27459
Comments
As noted in the documentation for However, the fact that the This feature was just a bonus stretch goal at the end of another project, so I think it's unlikely we'll be able to spend much more time on it in the near future, but nonetheless I'm going to relabel this as an enhancement with the intent that it represent a more complete design for development overrides, without this confusing oddity. The assumption that we'd do such a thing at some future point is what prompted the inclusion of the final paragraph of the docs:
|
Other provider developers including myself have run into similarly confusing situations with the development overrides and |
Actually it seems like the logic is already present and working for me with Terraform 0.14.4:
Maybe moving that above everything, similar to #27507 can make the behavior more obvious. 👍 |
What if my tf code contains two providers: a local one being looked up via |
Indeed, once you are using I think the main requirement for a full solution to this problem is ensuring that running In particular, that means it would not be correct to record a checksum of the override directory in the lock file, because that checksum would typically not be reproducible by anyone running Currently we meet this requirement by trying to install the upstream provider anyway and recording the lock file entries that result from it, even though that provider won't actually be used at runtime with the dev override in effect. It's possible that we could meet it a different way by omitting the overridden providers from the lock file altogether; I think if we did that we'd need to generate a loud warning that Terraform has produced an incomplete lock file, because that would subvert the typical |
In this scenario,
And
Seems like the only way to make this work is to override all providers or none? terraform 1.3.7 |
Yes, if you are developing with multiple providers at once then the easiest path is to make them all development overrides. This feature is here primarily for testing the one provider you are actively working on, so it's assuming you'll be working with a minimal configuration that only includes exactly what you are testing and nothing else. It's in that case where my suggestion to skip running init will work. If there are providers involved that are not the ones you are currently actively developing then that's outside the current intended scope for this feature, but you could work around it by pretending that you are developing those providers too and extracting their distribution packages onto your computer somewhere and adding |
I am running into an issue where I can't migrate state from local to S3 because I have a development override. I'm not sure if I should be using a development override - but it is the only way I've found to run a particular provider. Here's some info:
For the non-development-override approach, I have placed the binary at So... I need to find some way that lets me run the terraform-provider binary that I built, without looking it up on the registry, and also migrate state to S3. Any ideas? |
Hi @patmaddox, Development overrides are definitely not the appropriate thing to be using if you are doing anything other than development and testing of a single provider. For the situation you've described, the more appropriate configuration would be to either explicitly configure a local filesystem mirror or to place the provider package in one of the implied local mirror directories. It sounds like you've tried for the latter but note that |
Terraform Version
Description
With the following
~/.terraformrc
:And a new directory containing the following
main.tf
:Then
terraform init
should pick up the local override, however it instead pulls this from the registry:However this actually installs the latest version from the registry, currently v2.42.0:
Removing the
.terraform
and.terraform.lock.hcl
files, it's possible to runterraform plan|apply|destroy
just fine, using the local/development provider however:It's worth noting that if using a provider not available in the registry, such as an alias in this case to intentionally ignore it,
terraform init
fails instead. For example, updating the~/.terraformrc
to:and using the following
main.tf
:Returns a failure when using
terraform init
:But again a
terraform plan
(etc) work fine:As such it appears this failure is specific to
init
.References
The text was updated successfully, but these errors were encountered: