#terraform (2024-12)

I believe this is a bug with the component and with the remote-state call in particular: https://github.com/cloudposse-terraform-components/aws-tgw-spoke/blob/main/src/remote-state.tf#L12-L19

This module is missing enabled handling. When not enabled, we don’t care about the remote reference, so we can bypass it like this: https://github.com/cloudposse-terraform-components/aws-eks-cluster/blob/main/src/remote-state.tf#L19

See the related conversation here https://sweetops.slack.com/archives/CUJPCP1K6/p1733335296282389?thread_ts=1731100868.609129&cid=CUJPCP1K6

cc @Andriy Knysh (Cloud Posse) since he was the approver on #236 + likely has opinions here.

Personally, I’m not sure there is an easy way to make that new set of keepers not trigger a rebuild of that random_pet resource and therefore cause a rebuild of the cluster…

Now is that a breaking change… Probably?

@Jeremy G (Cloud Posse)

@Yangci Ou This is a complicated issue and will take significant time to resolve, if it can be resolved at all. My best guess is a solution will involve some kind of hack.

All of which is to say, please be patient, and stick with v1.12.0 for now.

cross reference to other thread https://sweetops.slack.com/archives/CUJPCP1K6/p1733518995283919?thread_ts=1731100868.609129&cid=CUJPCP1K6

Rollback of 1.13.0 and other enhancements released as v1.15.0

A better approach to using the default version is using the hashicorp/setup-terraform action and pinning to a specific version:

https://github.com/hashicorp/setup-terraform

@Erik Osterman (Cloud Posse) @Igor Rodionov any action item here?

@managedkaos @Gabriela Campana (Cloud Posse) @Erik Osterman (Cloud Posse) I think no. We already install Terraform explicitly with the action

Thanks for the info. My “you” statement in the original post was more of a PSA than a call out to the Cloud Posse team

But i do appreciate the follow up!

Is this an atmos question?

@Jeremy G (Cloud Posse)

@John Seekins For future reference, requests like this should go in #pr-reviews, as this channel is for more general Terraform questions, but we can keep this particular thread here.

This is an unusual use case, as evidenced by no one asking for it before now, even though IPv6 support was added over 2 years ago. As such, I’m hesitant to add these variables, as they can cause confusion. We already had a “master switch” in ipv6_enabled, and now we are adding suppression switches to limit it. @Michael is correct that the Cloud Posse standard is for feature flags to end with _enabled, but whether we use enabled or disabled, it is still confusing to me that you have the private and public features that have no effect unless the master feature is enabled.

I know the proposal I’m about to make is more obscure and a bit trickier to implement, but in some ways I prefer that for such a rare use case.

How about we do not add any new variables, but instead leverage the ipv6_cidrs object, adding optional private_enabled and public_enabled booleans defaulting to true? We can do the same for ipv4_cidrs and maintain feature parity between IPv4 and IPv6.

It’s true that we are still adding 2 (or 4) boolean suppression flags, but by keeping them somewhat buried, I think we make it easier for people to ignore them and not worry about them or expect too much from them.

I see what you’re asking, and that does make sense. My only pushback would be that if people ignore these new variables, the current behavior doesn’t change.

Why is that pushback?

Well…I’m just saying that we could leave these variables as-is and no one would notice the change unless they read the updated docs.

I’m not understanding your concern. My concern is that the module is already complex, and people using the module for the first time seeing:

• ipv6_enabled

• private_ipv6_enabled

• public_ipv6_enabled will be confused about the interaction among them, and wonder why there are no corresponding IPv4 flags.

Ah. Fair. I was thinking mostly about existing users.

Okay. I’ll see if I can add some settings inside the cidr objects.

Thanks for the feedback!

Terraform is for deploying infrastructure, not configuring nginx. All this is doable using Ansible . You do anything that’s automatable with Ansible. Or Saltstack or Puppet……. etc

hard work and grit?

in the trenches

only gotta do it once. grin and bear it

Yeah, just a bunch of busy work honestly

takes longer to try and find some magic tool than to just get it done

I bet and it’s not gonna adhere to our standards… tagging, organization, etc

exactly

Curious about this also.

This thread reminded me of this tool https://github.com/GoogleCloudPlatform/terraformer

But I haven’t personally used it before

Ok first crack at this and I was able to generate the resource code by first creating the import blocks of what I wanted to track, then used the terraform binary’s “generate-config-out” flag to specify where I wanted the resources to land in the workspace. Doing an apply brought the state up to date, then did a move block to move the resource into a newly created module. It wouldn’t let me import directly into the module. More to come, but probably in blog form

Hey @Joe Perez we import your entire Cloud and convert it into Terraform. Like Terraformer but we have implemented it from scratch as Terraformer doesn’t work well with the new plugin versions and provider versions www.opslycloud.com

https://github.com/suzuki-shunsuke/tfmv

Any chance you would also allow local state file manipulation?

I ran into an issue the other day where i needed to convert workspaces into a non workspace state so i needed to download 2 different states, dump all the resources names of each one to move it to a different address e.g. move from * (root) to module.green.*.

Your utility like it might be able to help if there’s a way to target a state file.

Very cool tool btw, good work

Maybe tfmigrator is what you want. • CLI: https://github.com/tfmigrator/cli?tab=readme-ov-file • Go library: https://github.com/tfmigrator/tfmigrator I archived these repositories as I have no plan to use them in near future, but I guess they still work. I developed tfmigrator before Terraform supported moved blocks. tfmigrator runs commands such as terraform state mv and terraform state rm instead of creating moved blocks.

Oh very nice. But since they are archived, for the problem case that i described, isn’t it possible to accomplish the same with move blocks?

Exactly.

Does moved block support moving resources across states?

I don’t believe so :(

State manipulation from workspace to workspace doesn’t seem possible

However if i could create moved blocks on a copied state then i could move resources from root * to module.example.* easily

Is it possible to generate move blocks using your tool to generate those?

Sorry. I don’t understand the meaning. As README shows, tfmv can edit resource names and create moved blocks like this.

-resource "github_repository" "example-1" {
+resource "github_repository" "example_1" {
   name = "example-1"
 }
 
 data "github_branch" "example" {
-  repository = github_repository.example-1.name
+  repository = github_repository.example_1.name
   branch     = "example"
 }

moved {
  from = github_repository.example-1
  to   = github_repository.example_1
}

https://github.com/suzuki-shunsuke/tfmv

create moved blocks on a copied state What does it mean?

Sorry maybe im not explaining right.

Can you move say all the resources from the parent root address to a module.xyz address using your tool to generate the moved blocks ?

No. For now tfmv supports renaming only resource names, meaning x.y => x.z or module.x => module.y . tfmv modifies *.tf, but if we move resouces from the parent root address to a module.xyz address, how should tfmv modify *.tf?

That would be tricky. I was thinking perhaps for that use case the tool could skip modifying existing resources ? Or maybe it’s the wrong tool for the job ? Idk. Im trying to avoid doing it by hand lol

I have already accepted that i need to manually create a module

I see. Thank you for your feedback. Indeed, sometimes we want to move resources across modules (a.b => module.c.a.d). So I’ll consider creating only moved blocks in that case.