Channels
#general
Title
# general
s
salmon-account-74572
04/26/2022, 3:05 PM@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
quiet-wolf-18467
04/26/2022, 3:24 PM
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
salmon-account-74572
04/26/2022, 3:28 PMRemoving 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
billowy-army-68599
04/26/2022, 3:30 PM
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
salmon-account-74572
04/26/2022, 4:03 PMIn general I agree; however, when there’s a constraint to modify existing groups what’s the best approach?
q
quiet-wolf-18467
04/26/2022, 4:05 PM
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
.getLet me know how you get on please 😀
s
salmon-account-74572
04/26/2022, 4:14 PMI’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
billowy-army-68599
04/26/2022, 4:19 PM
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