-
Notifications
You must be signed in to change notification settings - Fork 2.1k
refactor: Replace ListerWatcher with ListerWatcherWithContext #2724
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: main
Are you sure you want to change the base?
refactor: Replace ListerWatcher with ListerWatcherWithContext #2724
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: onasser1 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This issue is currently awaiting triage. If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the The 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. |
Welcome @onasser1! |
/hold |
internal/store/builder.go
Outdated
listWatchWithContextFunc func(kubeClient clientset.Interface, ns string, fieldSelector string) cache.ListerWatcherWithContext, | ||
useAPIServerCache bool, objectLimit int64, | ||
) []cache.Store { | ||
metricFamilies = generator.FilterFamilyGenerators(b.familyGeneratorFilter, metricFamilies) | ||
composedMetricGenFuncs := generator.ComposeMetricGenFuncs(metricFamilies) | ||
familyHeaders := generator.ExtractMetricFamilyHeaders(metricFamilies) | ||
var listerWatcher func(kubeClient clientset.Interface, ns string, fieldSelector string) cache.ListerWatcher |
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 listerWatcher
func will be removed (I prevent startReflector
from raising errors)
should be replaced with listWatchWithContextFunc
. further information I will explain at startReflector
function below
I haven't fixed/worked on tests yet, and still doing some changes so I'd prefer to keep this as a draft until I finish my changes and I'd mention you for a review, so you can ignore this for couple of days. I'd revisit this tomorrow. |
instrumentedListWatch := watch.NewInstrumentedListerWatcher(listWatcher, b.listWatchMetrics, reflect.TypeOf(expectedType).String(), useAPIServerCache, objectLimit) | ||
reflector := cache.NewReflectorWithOptions(sharding.NewShardedListWatch(b.shard, b.totalShards, instrumentedListWatch), expectedType, store, cache.ReflectorOptions{ResyncPeriod: 0}) | ||
instrumentedListWatchWithContext := watch.NewInstrumentedListerWatcher(listWatcherWithContext, b.listWatchMetrics, reflect.TypeOf(expectedType).String(), useAPIServerCache, objectLimit) | ||
reflector := cache.NewReflectorWithOptions(sharding.NewShardedListWatch(b.shard, b.totalShards, instrumentedListWatchWithContext), expectedType, store, cache.ReflectorOptions{ResyncPeriod: 0}) |
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.
issue:
newReflectorWithOptions
which is used from client-go
is taking a ListerWatcher
as an argument and inside its logic converts it to ListerWatcherWithContext
but we need to send ListerWatcherWithContext
from the beginning without the need of a cast.
https://github.com/kubernetes/client-go/blob/v0.33.3/tools/cache/reflector.go#L259
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 is a good catch. Do you want to work with client-go folks to update the implementation to support ListerWatcherWithContext as well?
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.
Absolutely Yes! but my question is should we update the parameter list to receive ListerWatcherWithContext
but wouldn't this make a dependency conflict? Or we should support another version of the function with different parameter list as we would do an override.
or Let's move this question to a new issue at client-go repo? WDYT?
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.
Since lister watcher without context is deprecated, I think we need a new NewReflector function in client-go. Yeah please open up an issue with client-go
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.
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.
If this is not possible, can I know why? thanks 😄
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.
There were too many existing APIs and structs which just pass through a ListerWatcher
, without actually doing anything with it. Changing all of those to have variants with ListWatcherWithContext
would have been a much bigger change, without some actual benefits.
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.
@pohly As Manuel Ruger seems kinda busy, can we move forward with this solution you proposed? What's your opinion?
If we can proceed with this, I'll wait for the approval from manuel with yours too.
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'd prefer to revisit the underlying assumption of this PR ("ListerWatcher is deprecated", which is not true) and instead address whatever linter warnings the current code gets without changing APIs.
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 Patrick, I've reached out to Manuel, but he is busy with the new release of KSM as it's the current priority, I think we will revisit this once he has capacity to review.
@dgrisonnet @rexagod Hi 👋🏻 I need help here, I guess I messed things up 🤔 |
Hi @mrueg 👋🏻 can you help me in your free time? |
Hi @onasser1, you definitely haven’t messed anything up. I’d recommend taking some time to get familiar with the codebase, that will help you build confidence and make it easier to contribute. I also suggest joining the bi-weekly meeting, where you can ask any questions you might have and get valuable insights into the code. That way, you’ll avoid falling into the trap. You’re already doing amazing work ,keep it up! Btw, maintainers and reviewers are at bandwidth, so please understand if they can’t always respond within your expected timeline. |
@assu-2000 thank you for kind words 😃 I plan to do this actually. |
What this PR does / why we need it:
ListerWatcher
is deprecated and we need to move KSM code to use insteadListerWatcherWithContext
How does this change affect the cardinality of KSM: (increases, decreases or does not change cardinality)
N/A
**Which issue(s) this PR fixes:
Fixes #2721