fix(argo): make fuzekeys-sealed self-heal from a failed first sync - #38
Draft
github-actions[bot] wants to merge 1 commit into
Draft
fix(argo): make fuzekeys-sealed self-heal from a failed first sync#38github-actions[bot] wants to merge 1 commit into
github-actions[bot] wants to merge 1 commit into
Conversation
The fuzekeys-sealed Application was the only app reported OutOfSync/Missing (conditions null). Its SealedSecret manifests are valid and consistent, but unlike the sibling fuzekeys-platform app it had no retry policy and no ServerSideApply: - On a from-scratch cluster Argo can attempt the first sync before FuzeInfra's sealed-secrets controller has registered the bitnami.com/SealedSecret CRD. The apply fails, the error lands in .status.operationState (not .status.conditions, which explains the empty conditions in the alert), and without a retry backoff the app stays latched OutOfSync/Missing until a manual sync. Add a retry block mirroring fuzekeys-platform so it self-recovers. - Add ServerSideApply=true so the large encryptedData blobs don't get a client-side last-applied-configuration annotation (262 KiB metadata limit) and kubeseal's creationTimestamp: null no longer diffs forever, which would keep the app OutOfSync even after the SealedSecrets exist. prune stays false (never auto-prune secrets); no finalizer is added so deleting the Application never cascades a delete of the live Secrets. Co-authored-by: Israel Weinberg <99821070+izzywdev@users.noreply.github.com>
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
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.
The fuzekeys-sealed Application was the only app reported OutOfSync/Missing
(conditions null). Its SealedSecret manifests are valid and consistent, but
unlike the sibling fuzekeys-platform app it had no retry policy and no
ServerSideApply:
sealed-secrets controller has registered the bitnami.com/SealedSecret CRD. The
apply fails, the error lands in .status.operationState (not .status.conditions,
which explains the empty conditions in the alert), and without a retry backoff
the app stays latched OutOfSync/Missing until a manual sync. Add a retry block
mirroring fuzekeys-platform so it self-recovers.
client-side last-applied-configuration annotation (262 KiB metadata limit) and
kubeseal's creationTimestamp: null no longer diffs forever, which would keep
the app OutOfSync even after the SealedSecrets exist.
prune stays false (never auto-prune secrets); no finalizer is added so deleting
the Application never cascades a delete of the live Secrets.
Co-authored-by: Israel Weinberg 99821070+izzywdev@users.noreply.github.com