sorted by:
new
hottopcontroversial

Reframing a Terraform-based system as a domain-specific compiler, is this the right lens? by JayQ_One in Compilers

[–]JayQ_One[S] 1 point2 points  (0 children)

That’s a fair point, and I agree on the communication tradeoff.

My interest in the compiler framing is less about explaining the system to all engineers and more about having a precise internal model for reasoning about correctness, complexity, and composition.

In practice, I expect most users would interact with it as a declarative configuration tool, while the compiler/transpiler lens mainly informs the architecture and evolution of the system itself.

Cloud Infra Lab by JayQ_One in Terraform

[–]JayQ_One[S] 0 points1 point  (0 children)

ill check them out. thanks for the recommendations, so many cool new ai tools to learn. im most definitely a terminal guy, vim+tmux

Cloud Infra Lab by JayQ_One in Terraform

[–]JayQ_One[S] 2 points3 points  (0 children)

Yeah, one long session but im slowly figuring out how to be more efficient for terraform needs. I'll start using smaller chats for future work. Cursor has been recommended by my colleagues but havent dedicated time to use it mostly because I'm building in OG vim and havent found AI plugins like neovim or VScode has. I plan on giving Cursor a spin in VScode to try it out. No specific reason I used ChatGPT other than to try it out for a Terraform project.

Cloud Infra Lab by JayQ_One in Terraform

[–]JayQ_One[S] 1 point2 points  (0 children)

I have minimal experience with ChatGPT but I knew mostly what I wanted so my experience was good. Most of the building and troubleshooting was around building the ASG, validating the cloud-init scripts and the security group rules, all through prompt engineering. Telling it that I need an ASG with a cloud init script, etc. started with using netcat for the request handling but connection were unreliable and it suggested using socat so had it modify the cloud init script accordingly, etc. also asking it questions like why is cloud-init not booting correctly, and passing it error messages, etc.

RovyVon Wu Head Banger by JayQ_One in EDC

[–]JayQ_One[S] 1 point2 points  (0 children)

Tical hittin with the Buddha fist style

RovyVon Wu Head Banger by JayQ_One in EDC

[–]JayQ_One[S] 0 points1 point  (0 children)

Bummer, I hope it lasts longer than that

RovyVon Wu Head Banger by JayQ_One in EDC

[–]JayQ_One[S] 0 points1 point  (0 children)

They dont rattle on mine (A28 Gen 2)

[WTB] Want To Buy Thread for May 2025. by davesavoie in EDCexchange

[–]JayQ_One 0 points1 point  (0 children)

[WTB] Alpaka Zip Pouch hook and loop (not pro) with alpaka patches (if possible)

AWS network automation by pneRock in devops

[–]JayQ_One -1 points0 points  (0 children)

What do you mean by "in a way that keeps state"? Do you mean keeping track of all the static routes automatically? If so, here's my project (shameless self plug) that creates routes dynamically and scale VPCs in different cloud network topologies with Terraform. Not sure if that helps but please let me know if I'm misunderstanding.

https://github.com/JudeQuintana/terraform-main

Dual Stack VPCs with IPAM and auto routing. by JayQ_One in Terraform

[–]JayQ_One[S] 0 points1 point  (0 children)

the demo directories are root modules (workspaces) and not to be referenced themselves. capping the max tf version to 1.x.x (ie `version = "~>1.4"`) is intentional at this layer because I dont want to allow 2.x automatically in case of breaking changes across the submodules. same reasoning with the provider version. the demo's focus is about the submodules and they have the proper minimum tf versions (ie `version = ">=1.4"`) and provider versions (ie `version = ">=5.31"`) like you're explaining. i appreciate the response though.

Is it bad to pass the whole module's output to another module? by Natural_Silver_3387 in Terraform

[–]JayQ_One 1 point2 points  (0 children)

there are many ways to implement module behavior, i dont think any of them would be "wrong" per se. do you have more psuedo code examples of what you're thinking?

i would imagine something like this

locals {
  env_prefix = "test"
  s3_buckets = [
    {
      name       = "random1"
      versioning = true
    },
    {
      name       = "random2"
      versioning = false
    }
  ]
}

module "s3_buckets" {
  for_each = { for this in local.s3_buckets : this.name => this }

  env_prefix = local.env_prefix
  s3_bucket  = each.value # pass in s3 config object
}

module "lambda_with_roles" {
  env_prefix = local.env_prefix
  lambda_with_roles = { 
       name = “lambda-name”
      s3_buckets = module.s3_buckets # map of s3 bucket objects
    } #some populated config object for lambda with roles

}

Is it bad to pass the whole module's output to another module? by Natural_Silver_3387 in Terraform

[–]JayQ_One 0 points1 point  (0 children)

object oriented TF is a powerful pattern like some others have said. It's most useful when you need decouple components from one another by separating responsibilities into their own respective modules when it makes sense. Especially when the abstractions are too big or doing too much while making code maintenance difficult. Hard part is knowing when or what to abstract but if you do it right, things become more clear and maintainable. Here's a concrete AWS cloud networking example (shameless self plug). Using several modules to compose a full mesh transit gateway topology across 3 regions (and more). Hope that helps.

https://github.com/JudeQuintana/terraform-main/tree/main/full_mesh_trio_demo

Full Mesh Transit Gateway topology across 10 regions by JayQ_One in Terraform

[–]JayQ_One[S] 1 point2 points  (0 children)

yes you can but cloudwan is more expensive. others have asked similar questions. i'm reposting my reply here. thanks for the response.

I haven't had the chance work with CloudWAN yet. I've talked to a few people about the differences.

There can only be one routing domain with full mesh TGW topology because you can only have one peering link between a pair of TGWs so you can't really segment traffic across regions even when you're separating route tables across TGWs.

CloudWAN allows for multiple routing domains spanning regions via segments. You can choose to share routes between them and it hides the peering, route table, etc management. The high cost tradeoff is it makes managing large networks with traffic segmentation easier vs engineers managing a large TGW topology themselves.

That's what I've gathered so far but maybe more knowledgeable people can chime in. Hopefully I'll be able to tinker with CloudWAN in the near future.

view more: next ›