#6513 may also be part of this effort.

Please see: #4817 (comment)

@fgrzadkowski I don't completely understand the tradeoffs involved in swapping out those lists for watches, thoughts on how we can avoid an Umbrella bug with %s/lists/watches down the line?

@bprashanth Sorry, but I don't understand your comment. I don't think there are any tradeoffs here. Semantically we will have exactly the same logic, but without reading the same objects multiple times.

Listing is less error-prone than watching. We should definitely support
clients that want to list frequently. The reported CPU saturation does not
make sense given the quantities of data involves, suggesting a pathological
bug. That should be fixed first.

On Tue, Apr 14, 2015 at 12:00 AM, Filip Grzadkowski <
notifications@github.com> wrote:

@bprashanth https://github.com/bprashanth Sorry, but I don't understand
your comment. I don't think there are any tradeoffs here. Semantically we
will have exactly the same logic, but without reading the same objects
multiple times.

—
Reply to this email directly or view it on GitHub
#6564 (comment)
.

@fgrzadkowski watching involves continuously filtering every change on the server as it occurs, while listing is just filtering all objects as they currently exist (so if an object goes from rv 1->100, all 100 are sent down the watch, but only the 100th will be sent down the list). I would expect watches to add some constant strain, especially since the watch also does a periodic list every 5 minutes.

@erictune Please see my example in this #6514 (comment)

@bprashanth I agree that listing is easier for some clients, but:
a) we already have simple libraries that make using watch very easy (watch-based cache)
b) current implementation of label/field selectors is sub-optimal
c) if we control some clients (such as controllers) we should make them as light-weight (from apiserver perspective) as possible. Obviously we will have to support lists and make them faster (see #6514 and #6800) but that's a completely separate story

After fixing #6518 situation improved but we still have high number (in terms of CPU usage) of lists. This happens in density test when replication controller creates new pods. I'm debugging what's the source (I don't think it's RC).

@wojtek-t

@rrati ^

Only remaining issue is #6562 so closing this one.