https://pulumi.com logo
Join Slack
Powered by
<@UCU9C7W73> Hey David, following up on a Twitter ...
# general
s
@quiet-wolf-18467 Hey David, following up on a Twitter thread from about a week ago. I posted that I’d noticed a flaw in my code. The issue pertained more to logic/code organization than anything else, I think, and before I wrote a blog post about what I found I wanted to check in here first and make sure I wasn’t overlooking something. Details in 🧵.
I have a “base infrastructure” stack that contains things that rarely changed and can be reused over and over (VPC, subnets, NAT gateways, etc.). In that stack were some security groups as well. I was finding that I needed to have “higher layer” stacks that built resources on top of the base infrastructure stack occasionally need to add a rule to these groups. Cool, no problem so far.
The problem comes if I need to refresh some part of the base stack (say, a bastion host needs to be rebuilt). Intuitively, I expected no issues, but because the security group definition in the base stack included some rules, then the new rules added by subsequent stacks were considered a “difference” and needed to be reconciled.
The only way around this, at least that I’ve found, is separating the creation/definition of the security group and the security group rules completely, i.e., no rules should be defined in the same code stanza where the group itself is defined.
So, my question(s): 1. Is the behavior I described expected, and have I correctly determined why this behavior occurs? 2. Is the workaround correct and a recommended/reasonable way of handling the situation?
q
I'd probably opt for adding new security groups in downstream stacks, but adding the new groups to the upstream VPC. I feel like modifying or adding rules to an existing group is a leaky abstraction and removes the idempotency from each layer.
Is there a constraint that means you need to modify existing groups instead of creating new groups?
s
Removing the idempotency (particularly from the base infrastructure layer) is the key issue, yes. In this particular instance, there is a constraint that requires I modify existing groups, but that won’t always be the case (so your point about creating new groups instead of modifying existing is well taken). That being said, would separating the definition of the group and the definition(s) of the rules in the code fix the idempotency issue? I haven’t completely finished refactoring my code so I haven’t had the issue to test yet (but I certainly can).
b
having a single security group and adding the rules downstream feels you're treating security groups like a firewall and the rules as firewall rules. you should have a security group per application/program. the security groups themselves should always live directly wth the thing that needs it
s
In general I agree; however, when there’s a constraint to modify existing groups what’s the best approach?
q
I'm not sure your second approach will work. I believe Pulumi will still detect the changes in the base layer, because IIRC the security group -> rule relationship is bidirectional and I'm curious if upstream will be confused by the addition? I'm out of office today, but I can run tests on Thursday - or feel free to share how you get on. I'm mighty curious
The other option (if your way doesn't work) would be to export the security group ID upstream and 
.get
it downstream.
Let me know how you get on please 😀
s
I’ll do some additional testing and let you know. No need to spend any of your cycles on this, I’m sure you have more important things to do!
b
In general I agree; however, when there’s a constraint to modify existing groups what’s the best approach?
😞 I think adding the rules is going to be your only option then
2 Views
Open in Slack
PreviousNext
Powered by