On Wed, Jan 20, 2021 at 9:56 AM Mark Goddard <mark@stackhpc.com> wrote:
On Tue, 19 Jan 2021 at 15:18, Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-01-19 12:56:41 +0000 (+0000), Sean Mooney wrote:
On Tue, 2021-01-19 at 12:37 +0100, Dmitry Tantsur wrote: [...]
I wonder if we could also run the plugin that shows the live progress (it was mentioned somewhere in the thread).
i belive showing the live progress of the jobs is effectivly a ddos vector. infra have ask that we not use javascript to pool the the live status of the jobs in our browser in the past. [...] i know that we previously tried enbeding the zuul job status directly into gerrit a few years ago and that had to be qickly reverted as it does not take many developers leave review open in a tab to quickly make that unworkable. i know i for one often leave review open over night if im pinged to review something shortly before i finish for the day so that its open on my screen when i log in the next day. [...]
I think it's probably worth trying again. The previous attempts hit a wall because of several challenges:
1. The available Zuul status API returned data on all enqueued refs (a *very* large JSON blob when the system is under heavy use)
2. Calls to the API were handled by a thread of the scheduler daemon, so often blocked or were blocked by other things going on, especially when Zuul was already under significant load
3. Browsers at the time continued running Javascript payloads in "background" tabs so the volume of queries was multiplied not just by the number of users but also by the average number of review tabs they had open
Over time we added a ref-scoped status method so callers could request the status of a specific change. The Zuul REST API is now served by a separate zuul-web daemon, which we can move to a different server entirely if load demands that (and can even scale horizontally with more than one instance of it, I think?). Browser tech has also improved, and popular ones these days suspend Javascript stacks when tabs are not exposed. We may also be caching status API responses more aggressively than we used to do. All of these factors combined could make live status info in a Gerrit plug-in entirely tractable, we'll just need someone with time to try it and see... and be prepared for multiple Gerrit service restarts to enable/disable it, so probably not when utilization is as high as it has been the past couple of weeks.
A refresh button to update live results on demand could be a good compromise between UX and unnecessary polling.
I'd be totally fine with a refresh button, very infrequent (once a minute?) automatic refreshes and aggressive caching.
On Thu, 2021-01-21 at 17:25 +0100, Dmitry Tantsur wrote: that kind of conter productive no. if you agressivly cache there is no point in frequent pooling i would consider anything less then 5 mints to be still relitivly frequent by the way so 1 minute is not very infrequent. a refresh button could work but my browser already has one of those.... personlaly if i want to monitor a specific job i use the zuul status page and filter it to just the job i want using the reivew number. that allows me to look at a whole series in one view too if i use the number of the first reivew in the series. im not really agaisnt live updates provide it does not bork things or cause undue load on the ci.
Dmitry
-- Jeremy Stanley