-
Notifications
You must be signed in to change notification settings - Fork 6.7k
fix(appset): do not trigger reconciliation on appsets not part of allowed namespaces when updating a cluster secret #25622
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
Conversation
❌ Preview Environment deleted from BunnyshellAvailable commands (reply to this comment):
|
|
LGTM |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #25622 +/- ##
==========================================
- Coverage 62.60% 62.59% -0.02%
==========================================
Files 353 353
Lines 49883 50150 +267
==========================================
+ Hits 31229 31390 +161
- Misses 15660 15740 +80
- Partials 2994 3020 +26 ☔ View full report in Codecov by Sentry. |
|
@argoproj/argocd-approvers : Hello guys, can I get a review for this fix of an annoying bug ? |
…llowed namespaces when updating a cluster secret Signed-off-by: OpenGuidou <[email protected]>
7ca201a to
cbca896
Compare
| Log: log.WithField("type", "createSecretEventHandler"), | ||
| Client: mgr.GetClient(), | ||
| Log: log.WithField("type", "createSecretEventHandler"), | ||
| ApplicationSetNamespaces: r.ApplicationSetNamespaces, |
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.
Seems like the method WithEventFilter(ignoreNotAllowedNamespaces(r.ApplicationSetNamespaces)). should also apply to the Secret type.
// WithEventFilter sets the event filters, to filter which create/update/delete/generic events eventually
// trigger reconciliations. For example, filtering on whether the resource version has changed.
// Given predicate is added for all watched objects and thus must be able to deal with the type
// of all watched objects.
Do you have an explanation why it is not the case?
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.
This correctly filters the cluster secrets in the correct namespaces, however the code inside createSecretEventHandler does a list on ApplicationSets at cluster scope without any filter on namespaces.
This PR fixes that
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.
So it should use the object.GetNamespace() for to list on a specific namespace and not all namespace instead.
afaik, Appset cannot use cluster secrets from another namespace than where they are defined right?
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.
In the case of Appset in any namespaces, they can.
Cluster secrets are in fact not allowed anywhere else than the controller namespace.
So we have this list of allowed namespaces for applicationsets as controller variable, that I'm just reusing here.
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.
Gotcha, but I think what you are doing is not officially supported based on https://argo-cd.readthedocs.io/en/latest/operator-manual/applicationset/Appset-Any-Namespace/#cluster-scoped-argo-cd-installation, most likely because cluster resource is access is required, but the event handling should work correctly.
Your code is good, but a small optimization could be that if the len(ApplicationSetNamespaces) == 1, use a ListOption to only list on the single watched namespace instead of cluster scoped. This would need a new unit test for 1 vs multiple allowedNamespace.
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.
Approving this PR still since it is an optimization and this PR by itself fixes the issue.
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.
I agree and it forces to have the list/watch rbac at cluster level even if it's not required. I don't think that's the only place we would have to change that...
Thanks !
|
@agaudreault could you add the labels for cherry picking on 3.X releases ? |
…owed namespaces when updating a cluster secret (#25622) Signed-off-by: OpenGuidou <[email protected]>
…owed namespaces when updating a cluster secret (#25622) Signed-off-by: OpenGuidou <[email protected]>
…owed namespaces when updating a cluster secret (#25622) Signed-off-by: OpenGuidou <[email protected]>
|
🍒 Cherry-pick PR created for 3.3: #25909 |
|
🍒 Cherry-pick PR created for 3.1: #25910 |
|
🍒 Cherry-pick PR created for 3.2: #25911 |
…owed namespaces when updating a cluster secret (cherry-pick #25622 for 3.2) (#25911) Signed-off-by: OpenGuidou <[email protected]> Co-authored-by: OpenGuidou <[email protected]>
…owed namespaces when updating a cluster secret (cherry-pick #25622 for 3.1) (#25910) Signed-off-by: OpenGuidou <[email protected]> Co-authored-by: OpenGuidou <[email protected]>
…owed namespaces when updating a cluster secret (cherry-pick #25622 for 3.3) (#25909) Signed-off-by: OpenGuidou <[email protected]> Co-authored-by: OpenGuidou <[email protected]>
Fixes #25621
Checklist: