[all][infra] CI test result table in the new gerrit review UI

Sean Mooney smooney at redhat.com
Thu Jan 21 17:27:12 UTC 2021


On Thu, 2021-01-21 at 17:25 +0100, Dmitry Tantsur wrote:
> On Wed, Jan 20, 2021 at 9:56 AM Mark Goddard <mark at stackhpc.com> wrote:
> 
> > On Tue, 19 Jan 2021 at 15:18, Jeremy Stanley <fungi at 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.
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
> > 
> > 
> 





More information about the openstack-discuss mailing list