skip db user actions when its secret failed to sync on update #2969
+69
−20
Conversation
This file contains hidden or 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
FxKu
requested review from
Jan-M,
hughcapet,
idanovinda,
jopadi and
sdudoladov
as code owners
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.
On UPDATE events the secrets sync can exit early on error but the database role sync will still happen. This will potentially override database passwords with what was generated in the initUsers step. Environment variables don't get overridden and Patroni can still operate, but apps (and even the operator when it happens to
postgresuser) will get "locked out".We could decide to not call syncRoles if the secret sync fails. We already do so if the initUsers step fails. During cluster creation and sync any error in SyncSecrets stops the entire sync loop as well. Only during update we care to process resources as much as possible.
Therefore, I chose a more fine-grained approach and still try to sync roles when the secret sync worked for them. I've added a new field in the pgUser struct to remember if the user is degraded or not. This logic will also be applied for cluster CREATE and SYNC events, meaning no database user would get created if the secret creation failed.