-
Notifications
You must be signed in to change notification settings - Fork 2
feat: add patch manager IaC #79
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
hrodmn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this! My only request is to export the pgbouncer instance names from the pgstacinfra stacks so we can provide the full names as props instead of just the stage name.
Do you think any of this could/should be fed back into eoapi-cdk's pgbouncer infrastructure?
| `MAAP-STAC-${props?.stage}-pgSTAC-pgbouncer`, | ||
| `MAAP-STAC-${props?.stage}-userSTAC-pgbouncer`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be best to provide the full instance names via props instead of just the stage. You might need to export the instance names in the other stack but it would be safer in case those instance names change for some reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough, I didn't add the condition to check that the other stack existed first but I can add that and export the name.
I think that it should in some sense, but looking at how we deploy the infrastructure it got a little messy when I was first defining it. I wouldn't want multiple maintenance windows/patch managers for our use case - one pgSTAC and one userSTAC but both are technically one environment. Do you think there's a way to define this infrastructure alongside the pgbouncer constructs without generating multiple maintenance windows/patch managers? or do you think I should add an optional default one that we wouldn't use in our case? |
I think it would make sense to add the capability to eoapi-cdk when pgbouncer is enabled since it shouldn't incur much cost (right?). I see why you would just want the one patch manager in this case, so maybe it would be nice to make it togglable. |
Description