<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 20, 2021 at 9:56 AM Mark Goddard <<a href="mailto:mark@stackhpc.com">mark@stackhpc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 19 Jan 2021 at 15:18, Jeremy Stanley <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>> wrote:<br>
><br>
> On 2021-01-19 12:56:41 +0000 (+0000), Sean Mooney wrote:<br>
> > On Tue, 2021-01-19 at 12:37 +0100, Dmitry Tantsur wrote:<br>
> [...]<br>
> > > I wonder if we could also run the plugin that shows the live<br>
> > > progress (it was mentioned somewhere in the thread).<br>
> ><br>
> > i belive showing the live progress of the jobs is effectivly a<br>
> > ddos vector. infra have ask that we not use javascript to pool the<br>
> > the live status of the jobs in our browser in the past.<br>
> [...]<br>
> > i know that we previously tried enbeding the zuul job status<br>
> > directly into gerrit a few years ago and that had to be qickly<br>
> > reverted as it does not take many developers leave review open in<br>
> > a tab to quickly make that unworkable. i know i for one often<br>
> > leave review open over night if im pinged to review something<br>
> > shortly before i finish for the day so that its open on my screen<br>
> > when i log in the next day.<br>
> [...]<br>
><br>
> I think it's probably worth trying again. The previous attempts hit<br>
> a wall because of several challenges:<br>
><br>
> 1. The available Zuul status API returned data on all enqueued refs<br>
> (a *very* large JSON blob when the system is under heavy use)<br>
><br>
> 2. Calls to the API were handled by a thread of the scheduler<br>
> daemon, so often blocked or were blocked by other things going on,<br>
> especially when Zuul was already under significant load<br>
><br>
> 3. Browsers at the time continued running Javascript payloads in<br>
> "background" tabs so the volume of queries was multiplied not just<br>
> by the number of users but also by the average number of review tabs<br>
> they had open<br>
><br>
> Over time we added a ref-scoped status method so callers could<br>
> request the status of a specific change. The Zuul REST API is now<br>
> served by a separate zuul-web daemon, which we can move to a<br>
> different server entirely if load demands that (and can even scale<br>
> horizontally with more than one instance of it, I think?). Browser<br>
> tech has also improved, and popular ones these days suspend<br>
> Javascript stacks when tabs are not exposed. We may also be caching<br>
> status API responses more aggressively than we used to do. All of<br>
> these factors combined could make live status info in a Gerrit<br>
> plug-in entirely tractable, we'll just need someone with time to try<br>
> it and see... and be prepared for multiple Gerrit service restarts<br>
> to enable/disable it, so probably not when utilization is as high as<br>
> it has been the past couple of weeks.<br>
<br>
A refresh button to update live results on demand could be a good<br>
compromise between UX and unnecessary polling.<br></blockquote><div><br></div><div>I'd be totally fine with a refresh button, very infrequent (once a minute?) automatic refreshes and aggressive caching.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> --<br>
> Jeremy Stanley<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>