https://cloudposse.com logo
Join Slack
Powered by
<@UB2EH889X> curious what direction you guys are g...
# atmos
z
@Erik Osterman (Cloud Posse) curious what direction you guys are going for maintaining your terraform modules?
Should I be referencing the 
ses
terraform module, or the atmos component
Copy code
ses:
      source:
        uri: "git::<https://github.com/cloudposse-terraform-components/aws-ses.git//src>"
        version: "v2.0.0"
OR?
Copy code
ses:
      source:
        uri: "git::<https://github.com/cloudposse/terraform-aws-ses.git>"
        version: "v0.25.1"
e
I understand there's confusion about this, but the answer is black and white
"components" are root modules
<http://github.com/cloudposse/*|github.com/cloudposse/*>
are child modules
Root modules are our opinionated usage of our modules.
Technically, child modules can be used as root modules; but root modules were never intended to be used as child modules.
So it comes down to if your architecture uses a lot of our root module components. If so, I would probably advise you stick with that.
But if you use mostly our modules, and maybe other community modules, then you probably stick with the module route.
And develop either your own components, or run the module directly.
My opinion is to keep atmos stack configs boring.
And that means moving most of the ugly string parsing, mapping, etc in HCL.
This is also why when Cloud Posse uses atmos, we use very little of the atmos functions for complex manipulations.
z
so just to clarify, we should be vendoring in the entire component?
e
Hrmm.... can. you clarify? What would vendoring a partial component entail?
😃
z
I guess at the end of the day both things I posted are still terraform modules, and looking at it we would consume both exactly the same this was wrong 😄
just one was updated released 2 months ago and the other 2 years ago
Actually looking at them side-by-side makes a lot more sense with what you're saying
it is root module vs child module
the component calls other modules, the module just does ses things
the ses component calls the ses module 🤦‍♂️
e
Yep
The root modules often lag behind the child modules
z
yeah I think that on our team we've kind of leaned more into having the terraform be super simple and having atmos do a lot of the heavy lifting? We are also working out of a large monorepo though, where access to all stacks/accounts is a little complicated
poking through that ses component I saw some modules where atmos would do cross stack state lookup etc, whereas atmos can do that pretty easily (recently) and just feed them in as input variables
our stacks are starting to look more like helm charts
which, as long as we are consistent, maybe won't end up so bad
e
(also, we've accept PRs to update components as well)
The git-aware atmos capabilties are pretty nice.
So I can understand breaking it out that way in a monorepo
I would love to learn more what you're doing.
You're definitely using every new feature of atmos!
4 Views
Open in Slack
PreviousNext
Powered by