-
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
🌱 Refactor internal cache/informers map impl #2103
🌱 Refactor internal cache/informers map impl #2103
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: 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 |
f637164
to
4a1bb11
Compare
/assign @alvaroaleman @sbueringer |
/retest |
ac5c3d7
to
f4563b1
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.
Just some nits, overall lgtm
pkg/cache/internal/informers_map.go
Outdated
// in an InformerMap. | ||
type InformersMapOptionsByGVK struct { | ||
Selectors SelectorsByGVK | ||
Transformers TransformFuncByObject |
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.
No strong objection but it seems a bit odd to have "ByGVK" and then have TransformFuncByObject
.
Looking at TransformFuncByObject
it seems to essentially also use GVK
Set(runtime.Object, *runtime.Scheme, cache.TransformFunc) error
Get(schema.GroupVersionKind) cache.TransformFunc
Get directly works with GVK and only Set takes an Object but only uses it to infer the GVK.
Wondering if we could/should rename TransformFuncByObject
to TransformFuncByGVK
especially as I would say the main functionality is mapping from "something" to TransformFunc
in Get
and that is done by GVK
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.
Renamed, it was all internal functions fortunately
@@ -145,7 +152,7 @@ type specificInformersMap struct { | |||
|
|||
// Start calls Run on each of the informers and sets started to true. Blocks on the context. | |||
// It doesn't return start because it can't return an error, and it's not a runnable directly. | |||
func (ip *specificInformersMap) Start(ctx context.Context) { | |||
func (ip *InformersMap) Start(ctx context.Context) error { |
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.
Q: Was the error return parameter just added in case we want to return errors in the future? (as of now we only return nil)
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.
It was added to satisfy the Runnable
interface, the same (nil error returned in any case) was before in the deleg_map file
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.
Makes sense, thx for the info!
ListFunc: func(opts metav1.ListOptions) (runtime.Object, error) { | ||
ip.selectors(gvk).ApplyToList(&opts) | ||
return lw.ListFunc(opts) | ||
}, | ||
WatchFunc: func(opts metav1.ListOptions) (watch.Interface, error) { | ||
ip.selectors(gvk).ApplyToList(&opts) | ||
opts.Watch = true // Watch needs to be set to true separately | ||
return lw.WatchFunc(opts) | ||
}, |
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.
Q: would it make sense to do this in makeListWatcher
so that makeListWatcher
alredy creates the final ListWatch
vs having "layered" ListWatches?
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.
Originally it was in each list watcher creation function, although the code was duplicate between each watch/listfunc, which was a bit repetitive. Do you see another way to do this that doesn't end up in repetition?
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 see the following options:
- write the listFunc and watchFunc in makeListWatcher inside the switch in variables and then build the ListWatch like it is done here at the end of the makeListWatcher func
- writing the ListWatch'es in makeListWatcher in a var and then add this code at the end of the makeListWatcher func
- defining inline modifyListOptions modifyWatchOptions func in makeListWatcher and calling them in each case
I would probably go with option 1, but also fine to just keep it as is if you want to
f4563b1
to
aff10e3
Compare
Signed-off-by: Vince Prignano <vince@prigna.com>
ccd3222
to
24812a3
Compare
Signed-off-by: Vince Prignano <vince@prigna.com>
24812a3
to
384ffbc
Compare
return list, err | ||
}, | ||
// Setup the watch function | ||
WatchFunc: func(opts metav1.ListOptions) (watcher watch.Interface, err error) { |
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.
WatchFunc: func(opts metav1.ListOptions) (watcher watch.Interface, err error) { | |
WatchFunc: func(opts metav1.ListOptions) (watch.Interface, error) { |
nit: maybe get rid of the named return parameters if we don't really need them anymore
(fine if you want to keep it)
@@ -145,7 +152,7 @@ type specificInformersMap struct { | |||
|
|||
// Start calls Run on each of the informers and sets started to true. Blocks on the context. | |||
// It doesn't return start because it can't return an error, and it's not a runnable directly. | |||
func (ip *specificInformersMap) Start(ctx context.Context) { | |||
func (ip *InformersMap) Start(ctx context.Context) error { |
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.
Makes sense, thx for the info!
ListFunc: func(opts metav1.ListOptions) (runtime.Object, error) { | ||
ip.selectors(gvk).ApplyToList(&opts) | ||
return lw.ListFunc(opts) | ||
}, | ||
WatchFunc: func(opts metav1.ListOptions) (watch.Interface, error) { | ||
ip.selectors(gvk).ApplyToList(&opts) | ||
opts.Watch = true // Watch needs to be set to true separately | ||
return lw.WatchFunc(opts) | ||
}, |
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 see the following options:
- write the listFunc and watchFunc in makeListWatcher inside the switch in variables and then build the ListWatch like it is done here at the end of the makeListWatcher func
- writing the ListWatch'es in makeListWatcher in a var and then add this code at the end of the makeListWatcher func
- defining inline modifyListOptions modifyWatchOptions func in makeListWatcher and calling them in each case
I would probably go with option 1, but also fine to just keep it as is if you want to
/retest |
/lgtm |
This is a first of a series of cleanups of our internal libraries, which has been long overdue. There are two commits in here, which we can also separate in different PRs if needed. The first pass simplifies w/ adding options to the implementation, the second refactors the map by removing the delegating map logic, which had lots of repetition and created confusion in the past.
Signed-off-by: Vince Prignano vince@prigna.com