4 ms·
Ok I may absolutely have the dumb today I appreciate the response. The way this is worded, because of this line - "Modules are the main way to package and reuse
by swozey 3y ago
Ok I may absolutely have the dumb today I appreciate the response. The way this is worded, because of this line - "Modules are the main way to package and reuse resource configurations with Terraform." reads like - "I have 10 golang apps, they all at a minimum use these same services, this is our "golang root module". But some services might have more or less modules, ie service A uses redis, service B uses kafka without redis.
So in this verbiage, is every single "stack/app" a "root module" and if one of them has a different database/whatever module it's just using different child modules and the child modules are the big differentiator?
Just to kind of prove the root-module argument I'm making here, this post in here is confused on calling a "stack" a module as well https://news.ycombinator.com/item?id=37005949 https://news.ycombinator.com/item?id=37005949
- rcrowley 3y agoGlad we cleared up our terminology! I agree that “root module” risks ambiguity, just like you point out. I just realized I never responded to the very last point in your original comment. I don’t have, and I don’t think Terraform has, a complete solution to dependencies between root modules. Fortunately, data sources will at least fail if they don’t find what they’re looking for. For me, these failures never come up in production since I’m never using `terraform destroy` there. It does come up in pre-production testing and that’s an area that seems rich with patterns and products on top of Terraform that are controlling order and dependence between root modules. PS thanks for your work on Terraform and Kubernetes.
- xomodo 3y agoUse 'terraform destroy' during CI phase. That is your pre-prod.
- xomodo 3y agoRoot-module: contains resources, sub-modules, incl. remote module calls. Stack: deployable with hardcoded tfstate and tfvars configs.