-
Couldn't load subscription status.
- Fork 84
fix(controller): prevent NodeAgent restarts from ESO metadata updates #1999
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: oadp-dev
Are you sure you want to change the base?
fix(controller): prevent NodeAgent restarts from ESO metadata updates #1999
Conversation
Fixes ESO-234: NodeAgent was restarting every ~30s when External Secrets Operator managed the cloud-credentials secret. ESO's metadata-only updates were triggering unnecessary DPA reconciliations. Changes: - Updated labelHandler.Update() to skip reconciliation for Secret objects when only metadata changes (ResourceVersion, annotations, etc.) - Added comprehensive unit tests for labelHandler covering all scenarios - Maintains backward compatibility for non-Secret resources This prevents unnecessary NodeAgent daemonset updates while preserving reconciliation for actual data or label changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
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 @kaovilai ! Please do not cherry pick until 1.5.3. is GA :)
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: kaovilai, weshayutin The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| // This filters out metadata-only updates (ResourceVersion, ManagedFields, etc.) | ||
| if reflect.DeepEqual(oldSecret.Data, newSecret.Data) && | ||
| reflect.DeepEqual(oldSecret.StringData, newSecret.StringData) && | ||
| reflect.DeepEqual(oldSecret.Labels, newSecret.Labels) { |
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.
@weshayutin although.. do we know if they are changing label every 30 seconds? are we supposed to ignore label changes?
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.
Couple notes that I have would be.
- I could be wrong but it's my understanding the external secrets operator is tech-preview.
- I'm not the smartest guy in the world but it seems to me that ESO should check the secret but if no change is required, I think ANY metadata on the secret should remain UNCHANGED, hence why I moved the bug to ESO.
- I DO like being defensive in this case, and we either need to set it up and try/test or enquire w/ the ESO team re: labels.
- I don't think this is a priority for our attention atm based on my above understanding. I could be wrong though.
|
/retest ai-retester: The end-to-end test |
|
/retest ai-retester: The e2e test failed because the |
|
@kaovilai: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Fixes ESO-234: NodeAgent was restarting every ~30s when External Secrets
Operator managed the cloud-credentials secret. ESO's metadata-only updates
were triggering unnecessary DPA reconciliations.
Changes:
when only metadata changes (ResourceVersion, annotations, etc.)
This prevents unnecessary NodeAgent daemonset updates while preserving
reconciliation for actual data or label changes.
🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com
Why the changes were made
How to test the changes made
Continuation of #1998 on a thawed oadp-dev branch.