fix: add component that configures unicorn pgbouncer image#162
fix: add component that configures unicorn pgbouncer image#162
Conversation
cross-du
changed the title
|
Full scan comparison results are too large to post as a comment. Link to full results artifact: Results registry1.dso.mil/ironbank/opensource/zalando/postgres-operator
|
| ./zarf tools wait-for postgresql pg-cluster -n postgres '{.status.PostgresClusterStatus}'=Running | ||
| fi | ||
|
|
||
| - name: connection-pooler |
There was a problem hiding this comment.
Flavor specific configurations do not belong in the common/zarf.yaml, but rather the root zarf.yaml
Additionally, I did not dig into it, but this seems like something that is likely able to be set via one of the charts values files. Did you look into if you could do that before taking this approach? Patching resources via kubectl would be the path of last resort for how to configure something.
Finally, why would this be in its own component rather than an onDeploy.after in the existing component?
There was a problem hiding this comment.
So this component should be moved to zarf.yaml?
That would be ideal, but the values for the connection pooler are scant. Maybe a better approach is to create a custom deployment template?
I made it a separate component so I could use only.flavor. Our customer encountered this issue with the unicorn flavor.
There was a problem hiding this comment.
Yes, you would be able to do it in the root level zarf.yaml, under the existing unicorn component, instead of in the common/zarf.yaml.
I also wonder though if there is a better way to configure this. If the helm chart does not have values for this, is it something that can be set configurable here?
https://github.com/uds-packages/postgres-operator/blob/main/chart/templates/postgres-minimal.yaml
There was a problem hiding this comment.
Okay, that makes sense. Thanks, Cody.
I'm not sure, but I'll give it a shot.
There was a problem hiding this comment.
Yes and there is already only.flavor in the root level zarf.yaml for unicorn.
Looking at this deeper it seems like the environment vars should be getting set automatically, but the user/group is "wrong" on this particular image and need to be changed for it to function correctly. It also seems like the user/group that gets assigned to the deployment is hardcoded in the go code.
I need to look into this more, but it seems like the ideal fix is probably swapping out the image, the provider offers several versions.
In order to ensure the proposed change can be validated and not become a problem again, but could you please provide a minimal reproduction of the issue(a test) that would replicate the problem. We generally will add such tests when we run into something like this to ensure we dont have regressions, especially if we change image providers. I can take that and validate all the flavors and bring back to the provider to either have them update the image we are using or get an entitlement to a different image and see if it can be resolved that way.
Thanks.
There was a problem hiding this comment.
It's not possible to set security context or environment vars in postgres-minimal.yaml. The extent of the connection pooler's configuration can be found here.
The docs also state that security context is hard coded.
Would moving the component to the root zarf.yaml be okay, or should I figure out how to deploy a custom template?
3 participants
Description
The pgbouncer image provided by RapidFort is not configured to work with the upstream chart. This PR adds a Zarf component that sets the correct environment variables and security context for pgbouncer to operate.
Related Issue
Fixes #
https://github.com/defenseunicorns/mission-success/issues/586
Type of change
Checklist before merging