-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
✨ Allow configuring a default cache selector #1710
✨ Allow configuring a default cache selector #1710
Conversation
b1f91f5
to
0c219e7
Compare
/assign @joelanford @vincepri |
0c219e7
to
b96f2c1
Compare
pkg/cache/cache.go
Outdated
// SelectorsByObjectDefaultKey can be used in SelectorsByObject to configure a default | ||
// selector for all kinds that do not have a specific selector set up. | ||
type SelectorsByObjectDefaultKey struct{ metav1.Object } | ||
|
||
// GetObjectKind implements runtime.Object. | ||
func (s *SelectorsByObjectDefaultKey) GetObjectKind() schema.ObjectKind { | ||
return schema.EmptyObjectKind | ||
} | ||
|
||
// DeepCopyObject implements runtime.Object. | ||
func (s *SelectorsByObjectDefaultKey) DeepCopyObject() runtime.Object { return s } |
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.
Rather than encoding the default selector into the SelectorsByObject
option which requires this new exported SelectorsByObjectDefaultKey
type, is it possible to add a DefaultSelector
field to the options struct and then handle the setup internally?
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.
That's a great idea, updated the PR, PTAL
b96f2c1
to
4ef4218
Compare
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 fact, now we already have ObjectAll and GroupVersionKindAll.
In type DisableDeepCopyByObject map[client.Object]bool
, If developers use ObjectAll
as its key, it will be the default value. So how about reuse ObjectAll
in SelectorsByObject
to avoid defining a new option?
@FillZpp Brings up a good point that there's already a mechanism for this with I'm torn though. On one hand, I think a separate Interested on folks thoughts about introducing |
Right, that is where I got the idea from, I thought I remembered we did that but then couldn't find it :) So tbh I am thorn as well, the UX of having a top-level field is much better than a magic key but does that warrant making things differently? Also I feel like the selector option warrants it because it is likely going to be used more than the somewhat exotic To not get stuck in this question I would suggest to only add a magic key and not a top-level option for now. If we later find that ppl want to use this but have trouble finding the magic key we can still add a top-level option without breaking compatibility (by copying its value into the magic key entry). WDYT @joelanford ? |
@joelanford could you have another look, please? |
pkg/cache/cache.go
Outdated
// Use SelectorsByObjectDefaultKey as key to specify a default selector that | ||
// will be used for all types that do not have a selector configured. |
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.
Is this comment still valid?
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.
err after the back-and-forth regarding magic key vs config option I decided to use the magic key, as it is easy to add a config option later but not easy to remove it again: #1710 (comment)
Apparently I forgot to update the code though 😬 did that now.
I ended up not re-using the ObjectAll
because it is a default that doesn't apply to everything, just to everything that doesn't have a setting so the name might cause confusion.
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 ended up not re-using the ObjectAll because it is a default that doesn't apply to everything, just to everything that doesn't have a setting so the name might cause confusion.
Emm.. I'm confused that the default and all here seem to be the same semantics? They all mean the default configuration for all kinds of object, except the objects that have their specific values.
@@ -203,6 +209,7 @@ func convertToSelectorsByGVK(selectorsByObject SelectorsByObject, scheme *runtim | |||
} | |||
selectorsByGVK[gvk] = internal.Selector(selector) | |||
} | |||
selectorsByGVK[schema.GroupVersionKind{}] = internal.Selector(defaultSelector) |
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.
nit not blocking
const defalutSelectorKey = schema.GroupVersionKind{}
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.
Needs to be a var but good idea, updated the code.
30ce6b2
to
0b22232
Compare
/retest |
/retest |
/retest |
@joelanford @vincepri could you have another look, please? |
pkg/cache/cache_test.go
Outdated
SelectorsByObject: cache.SelectorsByObject{ | ||
&corev1.ServiceAccount{}: {Field: fields.OneTermEqualSelector("metadata.namespace", testNamespaceOne)}, | ||
&cache.SelectorsByObjectDefaultKey{}: cache.ObjectSelector{Field: fields.OneTermEqualSelector("metadata.namespace", testNamespaceTwo)}, | ||
}, |
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.
Looking at how this is being used, if I understood what we're trying to do here correctly, we can summarize it as:
- For objects of type ServiceAccount, always cache only the objects in namespace 1
- For any other object, cache objects in namespace 2
If that's the case, I'm not super sure if I like this APIs, it's confusing that the fallback is also a "selector by object", which seems like a wildcard, although it could be confusing to users.
Have we thought instead of adding another option, like DefaultSelector
, or similar?
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.
@vincepri yes, see the discussion here: #1710 (comment)
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 would suggest to not add and deprecate any magic key in favor of a different field, it makes a nicer UX and easier understanding of the codebase. Without this test/example, it wouldn't have been clear what the PR was trying to achieve and how.
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.
Okay, reverted it back to add a top-level DefaultSelector
field, ptal.
0b22232
to
9ee0603
Compare
It is already possible to configure cache selectors per gvk, but it is not possible to default this selector for all types. This change adds that.
9ee0603
to
0b60488
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: alvaroaleman, vincepri 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 |
It is already possible to configure cache selectors per gvk, but it is
not possible to default this selector for all types. This change adds
that.
Fixes #1708