disable warning on init - Warning: Incomplete lock file information for providers

[oprudkyi]

Terraform Version

1.3.0

Use Cases

when lock file is unused really (recreated each time in ci/cd) there is always warning, which flood output with meaning-less info

>terraform init
...
╷
│ Warning: Incomplete lock file information for providers
│ 
│ Due to your customized provider installation methods, Terraform was forced to calculate lock file checksums locally for the following providers:
│   - hashicorp/google
│ 
│ The current .terraform.lock.hcl file only includes checksums for linux_amd64, so Terraform running on another platform will fail to install these providers.
│ 
│ To calculate additional checksums for another platform, run:
│   terraform providers lock -platform=linux_amd64
│ (where linux_amd64 is the platform to generate)
╵

Attempted Solutions

Proposal

Some option, like --ignore-lock-warning to disable warning entirely

References

No response

[apparentlymart]

Hi @oprudkyi! Thanks for sharing this feedback.

Can you say a little about why you don't include the dependency lock file in your version control, which would then cause you to see this warning only the first time you add a new provider or explicitly upgrade it?

I'm not meaning to suggest that it's wrong to not use the lock file, but our preference is to work towards addressing all of the shortcomings that are causing people to currently not use the lock file so that everyone will use the lock file, rather than constantly adding new workarounds for the people who aren't using it. That doesn't mean we cannot potentially do something more tactical like what you proposed here, but I would also like to add your situation to our set of feedback about the lock file behavior so that we can potentially make this situation moot for you in a later release.

Thanks!

[oprudkyi]

Hi @apparentlymart

We have some >400 root modules , basically this is some sort of self-service solution, where devs can manage infra/access without diving into complexity of tf - just by filling some abstract structures via PR (by example team/person has set of github reps and resources where it has access to, or standardized k8 clusters, where only few fields are needed to fill) , i.e. there is a set of many simple root modules - team, iam, application which managed by devs and set of modules which hides tf complexity inside, and managed by devops

and there is a problem of maintaining lock files

• most persons who make changes in configs do it via cicd style - create PRs, automation verifies etc. they can't run init locally because don't have access to state file, they often can't make qualified decisions about lock files content as well
• automatically updating lock files on PR/plan stage will flood git with technical information and won't help much (since can produce conflicts etc)
• making some script to update lock files periodically also don't provide anything useful, since there is the same situation as not having lock files at all

[yann-soubeyrand]

Hello,

It seems that the first time we do an upgrade of the providers we don’t get the warning, but if we do the upgrade in another workspace using the same provider we get the warning (since the providers aren’t downloaded again I guess [I’ve plugin_cache_dir = "$HOME/.terraform.d/plugin-cache" in my ~/.terraformrc file]). This is not ideal.

Regarding @oprudkyi’s first point, we’re also annoyed by the fact we cannot (or we haven’t found a way to) update providers without having state access and/or update a single provider.

[apparentlymart]

It should be possible to upgrade dependencies without accessing the state like this:

terraform init -upgrade -backend=false

The extra -backend=false tells Terraform that you don't intend to do anything involving state in this working directory and so there is no need to initialize the state storage.

With a working directory initialized in this way it's possible to run terraform validate to validate the configuration alone, which is actually the main purpose of this option (for automated validation as a pull request check), but even if you don't run any subsequent commands it can be useful just to run the initialization side-effects, such as updating the lock file.

terraform init -lockfile=readonly -backend=false can also be a good variant to run as a PR pre-check to catch situations where the lock file is not sufficient for the current configuration.

Of course if you aren't using the lock file mechanism at all then this is all moot, but I'm sharing it just in case it's useful or interesting.

[oprudkyi]

Hi @apparentlymart

the problem is not with backend, but with automation of lock files, there no point where I can integrate upgrading of lock files - users who create PR don't bother (and should not), PR by self is wrong place to update. The only option is avoiding them entirely.

alternatively, it would be great to centrally control lock files (or have one global), i.e. we currently have similar solution for terraform version, there is .env.terraform_version with

TERRAFORM_VER=1.3.0

and all triggers/actions use it, so devops can separately update version (and test it) without affecting other works,

probably shared lock file would work too, but then it should somehow be merged/shared between many root modules (we can do it with softlinks), but different root modules use different set of providers - again we probably can use shared list of providers

but I would prefer to hide warning, the problems I had with providers (broken github, google cloud) can be solved via required_providers and lock files there is less usable

[grimm26]

We also don't use the .terraform.lock.hcl and find this warning more spam from terraform. We lock down providers using the required_providers block and that works fine for us. Trying to control and manage yet another place to lock down provider versions that also keeps nagging me about including multiple platforms is just too much. Plus, I know that I only care about one platform because all of our terraform work happens on linux_amd64 and for the life of me I don't see a way to tell terraform that I am satisfied with the included platforms in .terraform.lock.hcl.

[Pesticles]

@apparentlymart I think I understand the problem you guys are trying to solve with these lock files, but I hope you realise that this change is going to break (or at least impair) a lot of peoples CI/CD processes.

Here's our use case. We generate parts of our stacks on-demand every time we use them, to include various boilerplate and to work around some deficiencies in TF, we also prefer to always use the latest versions of providers and modules, only pinning when there are problems which cannot be resolved any other way. Maintaining these lock files would be annoying, expensive, and we don't want to lock versions anyway.

If not maintaining these lock files will break the local caching (as noted in the 32205 ticket above) then they must effectively be considered a requirement, since the performance impact would be considerable in our environment, and the constant warning messages are annoying too.

[prowlaiii]

FYI, I just had this error when I put plugin_cache_dir = "$HOME/.terraform.d/plugin-cache" in my $HOME/.terraformrc and ran some "terraform plan"s in parallel. I just took it out again, so no major issue for me.

[edromero]

For our use case we don't include the dependency lock file in our version control because we version and bake the providers into a docker image that is then used by everyone else

[avesst]

For our use case we don't include the dependency lock file in our version control because we version and bake the providers into a docker image that is then used by everyone else

Same use case here. We use Terraform in a CI pipeline which runs terraform init ~10 times depending on environment and this causes a lot of spam.

plan and apply has -compact-warnings as option, maybe we can get that for init as well, or an option to disable this specific message entirely.

[pauldraper]

Can you say a little about why you don't include the dependency lock file in your version control

CI:

1. Compile the Terraform provider(s).
2. Run terraform apply.

Simple.

For no part of that is a lockfile relevant or helpful.

---

If you use Terraform to resolve and download providers/modules from Hashicorp registry, it is useful. But for everyone else, it's simply noise.

[pauldraper]

Rediscovered this ticket here.

What the heck is Terraform expecting me to do!??!?!?!

Compile my plugin for every operating system and platform, just to run it on my operating system and platform?!?!??!? To fulfill some philosophical itch???

Please explain why anyone, ever thought this ^ was a good idea.

I want a glimpse into insanity ^