Hey David following up on a Twitter thre

Question

< 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 thread

salmon-account-74572 · Answer

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

salmon-account-74572 · Answer

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

salmon-account-74572 · Answer

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

salmon-account-74572 · Answer

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

quiet-wolf-18467 · Answer

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

quiet-wolf-18467 · Answer

Is there a constraint that means you need to modify existing groups instead of creating new groups

salmon-account-74572 · Answer

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

billowy-army-68599 · Answer

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

salmon-account-74572 · Answer

In general I agree however when there s a constraint to modify existing groups what s the best approach

quiet-wolf-18467 · Answer

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 gt 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

quiet-wolf-18467 · Answer

The other option if your way doesn t work would be to export the security group ID upstream and ` get` it downstream

quiet-wolf-18467 · Answer

Let me know how you get on please grinning

salmon-account-74572 · Answer

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

billowy-army-68599 · Answer

gt In general I agree however when there s a constraint to modify existing groups what s the best approach disappointed I think adding the rules is going to be your only option then