launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #06527
Re: QA-ing on qastaging
On Thu, 2011-02-17 at 06:50 +1300, Robert Collins wrote:
> On Thu, Feb 17, 2011 at 6:31 AM, Henning Eggers
> <henning.eggers@xxxxxxxxxxxxx> wrote:
> Running all cron scripts on staging and qastaging is a first step but not
> > ideal either because they usually run at longer intervals which again
> > increases the slow-down.
>
> We are moving a dedicated machine to run these scripts for [qa]staging
> - they should run at production frequencies [except things that
> involve external sites, which we can't run atm].
>
> > A launch page would be great where I as a developer could go and manually
> > trigger a run of any of the scripts and cronscripts in the tree, ideally
> > passing in parameters and even stdin. It might be useful to organize some sort
> > of exclusive access around these, though.
> >
> > The ideal solution would be, of course, to have access to a shell, even a
> > restricted one. Scripts run from that shell could be monitored closely and
> > terminated automatically if they consume too much resources, giving an
> > appropriate error message.
> >
> > Related but not the same problem: Having some "sudo" in the UI would be great
> > where I could easily take ownership of a project or team or add myself to any
> > team. Right now, this involves a LOSA loop, too.
> >
> > I find the current situation very counter-productive and doing something about
> > it seems important for our velocity. Are there other possible solutions to
> > unblock us on QA that I am not seeing?
>
> FWIW I'd be fine with any of these if done /really carefully/ : there
> is plenty of opportunity for inappropriate disclosure to end users if
> we have a bug with any of these - particular high risk ones like
> submitting shell parameters and input over the web UI.
>
> However, the LOSAs are hiring, and as they get more resources should
> be able to assist more promptly.
This is true, and is going to help to some extent. At the same time,
there's still going to be the issue of needing handoff from a human to a
human, and any time that happens there will inevitably be some delay.
It's a difficult problem to solve, as any programmatic solutions would
take a long time to implement properly, and have their drawbacks as
well.
Would the process be any smoother (if not immediately quicker) if you
could queue up QA requests, and then walk away and focus on something
else, rather than needing the back and forth of IRC interaction with
LOSAs? I'm wondering if it would be better to create RTs for this so
that you don't have to sit on IRC waiting for a response. I realise it
wouldn't be any quicker, but it should allow you to focus on other stuff
and get notified when we actually get around to it. For this to work
well it would depend on:
- You knowing and being able to describe in an RT everything you need in
a lot of detail (so we don't need to come back to you and ask you
questions about things like which user it needs to run as, where it
should run from, etc.). We could fairly easily create a template of all
the things we need to know that you would fill out for a QA request like
this.
- Us responding to the RTs quickly enough for it not be a blocker.
Thanks, Tom
> -Rob
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help : https://help.launchpad.net/ListHelp
Follow ups
References