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

Support specific terraform versions #7

Open
henrjk opened this issue Jan 2, 2024 · 6 comments
Open

Support specific terraform versions #7

henrjk opened this issue Jan 2, 2024 · 6 comments

Comments

@henrjk
Copy link
Member

henrjk commented Jan 2, 2024

The tool tfenv (https://github.com/tfutils/tfenv) is a candidate to support flexible terraform versions.

One would want to have the terraform version be cached in the ods-pipeline cache so that the installation could be reused in multiple pipeline runs. Is there a setting that would allow this (perhaps TFENV_CONFIG_DIR).

If there are issues with using tvenv would an alternative approach work?

@tbugfinder
Copy link

I was wondering if the ods tooling might rather switch to asdf as a more generic version manager for multiple dependencies.

Ref: https://asdf-vm.com/

@kvendingoldo
Copy link

Try to use tenv to manager your Terraform/OpenTofu installations.

@henrjk
Copy link
Member Author

henrjk commented Jan 29, 2024

@kvendingoldo and @tbugfinder thanks for the suggestions. Can you share a bit more on why asdf-vm or tenv might be better choices than tfenv?

@kvendingoldo
Copy link

@henrjk tenv is a successor of tfenv and tofuenv. It's a native golang binary that does not require and shell dependencies and support OpenTofu as well as Terraform. In the near future, it also will have support of Terragrunt.

The most important thing - we saved the compatibility with tfenv and 90% of commands looks the same.

@tbugfinder
Copy link

@henrjk I'd prefer asdf as it supports not only terraform or opentofu but many more.
So it could be selected as a general version manager within this project (beyond the repo) and the repo would be enabled for other components to manage.

@henrjk
Copy link
Member Author

henrjk commented Jan 31, 2024

Thanks @kvendingoldo and @tbugfinder for your feedback!

This tasks' misson is to provide terraform support. While OpenTofu support is probably at least as important, it would be implemented in a different task/repo. That said having a solution that works for both (and perhaps other tools) would reduce complexity when one needs to use both in different contexts.

However I am not certain that installing a terraform version during task runtime is desirable taking concerns regarding security and separation of building and running a task into account.

While the existence of this issue suggests that one terraform version would not be sufficient for terraform I am not so sure this is a fact. So far other ods-pipeline-* tasks only package one version of the tools that the task utilizes. And perhaps it would be sufficient to simply update that version from time to time.

An alternative could be to publish two different task images for the 2 most recent minor terraform versions:

  • terraform-17: which would be provide the latest v1.7.x version as of image building.
  • terraform-16: similar for v1.6.x

They would both include the same deploy-terraform executable which would also be tested to be compatible with the included terraform tool versions.

Now once a v1.8 is released terraform-16 would be replaced with terraform-18 and thus no longer be updated. It appears consistent with Support Period and End-of-Life (EOL) Policy and endoflife.date - Hashicorp Terraform. The latter suggests that minor versions of terraform come about frequently, so ideally rebuilding the images to adopt new versions should be mostly automated.

Would a single or two version approach be sufficient for using terraform and perhaps be more desirable? What cases would be problematic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants