Open Stack

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.

Dmitry


>
> > --
> > Jeremy Stanley
>
>

-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210121/9cf624dd/attachment.html>