Terraform 0.15 General Availability

Post by wooly_bully » Wed, Apr 14, 2021, 10:11 PM UTC

dastx wrote: post #60

wooly_bully wrote: post #59

Earlier quoted context omitted.

The 'not using HCL' bit is really the only positive I've found so far because everything else has been more difficult than just using TF directly. I think my goals were slightly off from the beginning, because this is really just replacing one CLI with another for me at this point. What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can…

> What I want: Use Terraform programmatically, i.e. call "cdktf deploy" or similar FROM node or python and give users some scripts they can use where I can abstract away some of the difficulties of learning to use Terraform natively for simple use cases (i.e. deploy an S3-based frontend host). Maybe not node/python, but I'm pretty sure you can use terraform as a package in go. If not, there is always the "make temp d…

Post by garymoon » Wed, Apr 14, 2021, 10:12 PM UTC

llbeansandrice wrote: post #2

Perhaps off-topic but how have people upgraded TF codebases to new versions? Just last year we had a big effort to upgrade a huge code-base from 0.11 to 0.12. I feel like it should be a lot smoother than a full-team full-sprint effort.

  - Don't upgrade directly from 12 to 14, go to 13 first
  - If you have warnings after moving from 11, fix them first
  - Run the 0.13upgrade command in your code that will generate the required_providers
  - Run terraform-v13 init
  - Change to correct workspace if using some
  - Run terraform-v13 plan which will probably fail due to the new explicit required-providers rule, if that happens you need to modify the state with the correct providers https://www.terraform.io/upgrade-guides/0-13.html#why-do-i-see-provider-during-init- . In my case I have a lot of modules so I created an script that automated that process
  - Execute again terraform-v13 plan and verify that it will not make uncommon changes
  - Then run terraform-v13 apply.

Post by sciurus » Wed, Apr 14, 2021, 10:21 PM UTC

pizza234 wrote: post #52

Thaxll wrote: post #35

Earlier quoted context omitted.

There is no solution where 100k loc is not going to be challenging to keep over time.

While it's not possible to make an apple-to-apple comparison (Terraform-to-?), if we compare to something based on an imperative language, say Puppet or Chef, there is a huge difference. In my opinion, Terraform's big issue is that it was born as a declarative tool for managing infrastructure. Large configurations (IMO) necessarily ossify, because you don't have an imperative language that makes small progressive cha…

Post by ggregoire » Wed, Apr 14, 2021, 10:35 PM UTC

llbeansandrice wrote: post #50

mr_C wrote: post #45

Earlier quoted context omitted.

Maybe an unpopular opinion but what you just described as "naive" is arguably a better solution than Terraform's overengineering. I use Ansible to manage multiple clouds (Openstack, AWS...etc) using a mix of custom modules and public collections. I don't need a "state", I couldn't care less if resources exist or not, upgrades between versions are smooth, module/collection upgrades doesn't interfere with all the exist…

I haven't used Ansible so maybe I'm incorrect here but aren't tf and Ansible solving slightly different problems? Terraform feels like infrastructure management to me. We use it to provision underlying resources: Networking, Clusters, Nodes, Alerts, etc. All of the actual code deployments are entirely separate. Ansible is more of a configuration management right?

Post by [deleted] » Wed, Apr 14, 2021, 10:44 PM UTC

mr_C wrote: post #56

diroussel wrote: post #51

Earlier quoted context omitted.

If you have an ansible playbook that creates a certain resource, and you delete that code. Next time you run it, it won’t delete the resource because there is no state management. You have to add code to as only to be sure to remove the non-longer needed resource. But how long does that code need to stay there. Ansible is supposed to engender a decorative approach, but it’s very easy to slip into procedural code. Whe…

Who cares if there is a dangling dns records somewhere or an extra allocated floating ip? In practice you could just set state:absent to whatever you are trying to remove or just remove it manually, the latter is most of the time faster than dealing with state management once you have a behemoth in prod that no one wants to break.