Use case for plugin_cache_may_break_dependency_lock_file

[Porter]

Terraform Version

N/A, versions with the plugin provider cache

Use Cases

The plugin_cache_may_break_dependency_lock_file documentation states "If your workflow relies on the use of this option, please open a GitHub issue to share details about your situation..."

I have such a use case, and here are the details:

We essentially host Terraform as a Service, meaning clients send their terraform modules to us, and we'll continuously run tf plan and tf apply on the those modules.

Due to security requirements, every terraform command for a given module runs in an isolated container (gvisor). To save time/bandwidth, there is one terraform plugin cache dir per service. Each gvisor instance is given access to this dir.

Also note the gvisor containers are not kept around. When it's time to either plan or apply, a new gvisor container is created, the terraform module is loaded into it, the plugin cache dir is exposed via symlink/mounting (I'm not which one, but I don't think it matters), then tf init and then either plan or apply is executed in the gvisor container.

Since every time running tf init is the always the first time tf init is run in the container, there is no dependency lock file, so terraform will not use any providers from the cache.

Attempted Solutions

By setting plugin_cache_may_break_dependency_lock_file, terraform will use the providers in the cache.

An alternative approach for us would be to extract the dependency lock file from a container after it finishes tf init and use that, but this may be tricky, especially since we may have multiple gvisor containers running at once.

Proposal

No response

References

• plugin_cache_may_break_dependency_lock_file using a docker container to manage dependencies rather than a lock file #32906

[crw]

Thanks for this feedback.