Assign ownership of backup pvc to postgres image's uid #1854
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
|
@ranvit Note that AFAIK changing owner and permission for PVC is NOT required for all users, but only required for specific users e.g. on hostPath or longhorn on k8s. So adding init container with root privilege by default may cause side effects for those who are on the k8s or OpenShift where the issue does not exist. There is already similar implementation for PVC for PSQL to change owner and permission, so I think it would be better to follow existing implementation instead of going different way. How do you think? The exising implementation is having a flag to enable init container to invoke specific commands. Refer to: #1805 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SUMMARY
Backups are failing because the postgres image runs as uid 26 that doesn't have perms to the backup PVC. This fixes #1830
ISSUE TYPE
ADDITIONAL INFORMATION
The other option is to have the db-management pod run as root (uid 0), but I dont think thats the preferred solution.