Terraform version its too low

[ivorsmorenburg]

Describe the bug
Terraform version is too low and doesnt work terraform.options.version: "1.3.0" in bitops.onfig.yaml
To Reproduce

Expected behavior
BitOps should use that version

System info

• BitOps image tag used: 2.0.0
• Hardware: docker
• Tool: terraform

[mickmcgrath13]

Thanks for the issue @ivorsmorenburg!

BitOps should use that version

Which version should be used? 1.3.0?

For a little context, the TF version is determined by the TF plugin:
https://github.com/bitops-plugins/terraform/blob/main/install.sh#L13

We could take several approaches here:

1. install multiple versions of TF by the plugin
   This would probably be good for the Omnibus image, though it would add a bit of bloat.

2. Implement a versioning strategy for the TF plugin
   this is something we should admittedly do anyway. The question is:
   should the plugin version equal the TF version that is installed in it?

2.1) If we use the same TF version for the plugin version, there would be a bit of ambiguity in additional features of the plugin (e.g. if the terraform version is 1.3.0, but we add a new feature to the plugin, do we update the plugin version?).

2.2) It might make sense to version the TF plugin independently of the TF version and suffix the version with the TF version. Something like 1.0.0-tf1.3.0.

3. Fork the terraform plugin
   Users can fork the terraform plugin and modify as-needed, then create a custom docker container (docs)

One caveat with this approach is that it's additional overhead for users.

My preference would be option 2.2 (version the tf plugin version and tf version independently).

@armab thoughts?

[mickmcgrath13]

fwiw, there's a discussion here that we could prioritize:
#206

[arm4b]

When you're using the pre-defined BitOps image from Docker Hub, the Terraform version is already pre-packaged and it's not possible to control that from the bitops.config.yaml.

You could build your own BitOps image with a list of tools and versions you need. See https://bitovi.github.io/bitops/plugins/#creating-your-own-bitops-image.
However, an issue is that Terraform version is hardcoded there.

I see 3 issues here:

• Validation: BitOps should throw an error when trying to overwrite plugin settings terraform.options.version: "1.3.0" for a prebuilt BitOps image or using an inexistent plugin setting. I understand that was an initial misunderstanding. Bug bitops.config.yaml should be validated against the schema #237
• Terraform version is hardcoded in the plugin
• Missing version configuration for terraform plugin when trying to build your own BitOps

@ivorsmorenburg Can you please confirm what was the case when you tried to use terraform.options.version: "1.3.0" in bitops.config.yaml?

[ivorsmorenburg]

Thanks for all the info, don't think building my own image, or using a plugin, I see too much overwork for changing just the version.

No issues running that against the schema, it run fine but with the version already hardcoded in bitops andn ot the one specified.

[ivorsmorenburg]

Can we upgrade bitops to use TF 1.3.0 ? 😄

[arm4b]

@ivorsmorenburg

No issues running that against the schema, it run fine

Yeah, the bug here is that when you set a version in config terraform.options.version: "1.3.0" it didn't work, making you feel it worked instead of showing an error about an inexistent setting. #117

Can we upgrade bitops to use TF 1.3.0 ?

Sure. I'd assume when using an official BitOps image, do you expect to have everything latest by default in the tools we package, right https://bitovi.github.io/bitops/versioning/#official-images?

[ivorsmorenburg]

That's exactly my expectation :). Thanks!!!

[arm4b]

@ivorsmorenburg Sounds good. We'll bump the versions for all the tools and update you here.
It will likely come with the BitOps v2.1.0 image version in the next several days.

[ivorsmorenburg]

What about having something like https://github.com/tfutils/tfenv?

[arm4b]

@ivorsmorenburg Nice! Worth exploring, thanks for the link 👍

Allowing switching the plugin version on the fly for the official BitOps image via config would be nice, but then we should pre-package many versions for each tool as a rule and be consistent in our approach. It can take significant space for Ansible + Terraform + AWS + kubectl (https://bitovi.github.io/bitops/versioning/#official-images), etc, etc and fit everyone's needs to have several major + minor versions.

@mickmcgrath13 We can package a couple of terraform binaries, but that is rather a fix that doesn't scale, because there are other tools and versions.

The questions:

• how many major/minor versions do we want to pre-package for each tool?
• what if user-version specified is not what we pre-packaged?
• what to do with the patch versions, security fixes/updates for each major.minor?
• how much space overhead it'll take?

We could potentially experiment with that and see where it goes, but feels like the scalability is not there.
Alternative is allowing user to specify a version in the bitops config for the custom image they build (https://bitovi.github.io/bitops/plugins/#creating-your-own-bitops-image), while using all latest version for official pre-packaged BitOps images.

All approaches with their pros/cons.

[mickmcgrath13]

I agree.

1. Adding multiple binaries adds bloat that not everyone would want and doesn't scale (has implications of how many versions do we support)
2. Allowing on-demand TF versions adds to startup time of the tool (if not pre-packaged, it takes time to install for every deployment vs pre-packaged)
3. forcing users to create their own image is probably the most scalable approach but doesn't help for 'quick start' scenarios

I wonder if the best approach would be a hybrid of all?

1. we provide a pre-packaged set of common versions that can be selected via the terraform.options.version. with this, we could also probably provide versioned plugins with the 1.0.0-tf1.3.0 approach.
2. if the version does not exist, we install it on the fly (with something like https://github.com/tfutils/tfenv)
3. users can lower the deployment time/latency by creating their own image with succinct tf versions

additionally, we should have better error/warning messages about what happens when the terraform.options.version doesn't match what's installed/pre-packaged.

..and in any case, we need a consistent, reliable, quick way to ensure we can accommodate the use case of providing specific versions for tools.

for @ivorsmorenburg's immediate case, I think either

1. pre-installing multiple binaries (this would get us closer to the above hybrid approach)
2. we create a 1.0.0-tf1.3.0 version of the tf plugin and release a new omnibus image

[mickmcgrath13]

one other note: I am wary of simply upgrading the version of the plugin's installed tf from 1.2.2 to 1.3.0 in case there are breaking changes with existing ops repos that rely on 1.2.2. Is that a legitimate concern?

[ivorsmorenburg]

That's why having on-demand terraform versions its a very helpful thing for 'quick start' and more complex scenarios. Thats why with tfenv you define the version in each module .terraform-version.
It could take some time to download and install (few seconds) but that could be optional with a default binary in the image and the ability to switch if required.

This is very scalable, as the version its not a dependency. I see a lot of benefits having something like this.

[arm4b]

Terraform is easy as that's just a Go binary to download. If we want to be consistent in our approach, how do we properly support other versions and tools, say Ansible, which can take some time to build on fly (sometimes minutes, depending on the version because some sources have to be rebuilt)?

What if there are multiple versions the user is specifying for the Omnibus image: https://bitovi.github.io/bitops/versioning/#official-images

• terraform
• was-cli
• ansible
• helm
• kubectl

^^ all of that?

how much time that'll take together and what would be the user experience with BitOps if it's not pre-packaged software in a Docker image? An edge case, what if the BitOps plugin could install ansible v2.9, but the build/install fails on fly installing ansible v2.8 and the image is part of the production deployment pipeline?

These corner cases still remain open IMO.

[arm4b]

one other note: I am wary of simply upgrading the version of the plugin's installed tf from 1.2.2 to 1.3.0 in case there are breaking changes with existing ops repos that rely on 1.2.2. Is that a legitimate concern?

@mickmcgrath13 If we'll release it under the new BitOps v2.1.0 tag, users who used pinned v2.0.0 won't have any breaking changes.

Per #307 (comment) we can make all the future official BitOps images to rely on the "latest" tools, rather than on pinned.

• https://github.com/bitops-plugins/kubectl/blob/458d9c144c13073e4afa84cce8023aa4c68bbad5/install.sh#L17
• https://github.com/bitops-plugins/terraform/blob/b189c2dd7cb38e7e883837f0f3204e5b7e8a6e6b/install.sh#L13
• https://github.com/bitops-plugins/ansible/blob/29af954b11406546160229f60a23967ee42029c4/install.sh#L26
• https://github.com/bitops-plugins/helm/blob/cadf9eb0922d8d072735c41ee6c9c725cef0522a/install.sh#L14

We say that the fresh BitOps images are built based on the latest tools by default as that's probably the most expected behavior. That would be at least something. Agree?