[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH OSSTEST v2 01/18] apt: lock osstest's usages of apt-get against each other



On Tue, 2015-01-20 at 18:19 +0000, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2 01/18] apt: lock osstest's usages of 
> apt-get against each other"):
> > Currently we rely on all apt-get invocations being in a single
> > ts-xen-build-prep job which can't run on a shared host.
> > 
> > That is a bit inflexible so instead use our own lock. We wait
> > indefinitely and rely on osstest's existing command timeout
> > infrastructure to catch problems.
> 
> ...
> > diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
> > index e6c54bc..2ac490f 100644
> > --- a/Osstest/TestSupport.pm
> > +++ b/Osstest/TestSupport.pm
> > @@ -433,17 +433,18 @@ sub target_putfile_root ($$$$;$) {
> >  sub target_run_apt {
> >      my ($ho, $timeout, @aptopts) = @_;
> >      target_cmd_root($ho,
> > -   "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y apt-get @aptopts",
> > +   "DEBIAN_PRIORITY=critical UCF_FORCE_CONFFOLD=y \
> > +        with-lock-ex -w /var/lock/osstest-apt apt-get @aptopts",
> >                      $timeout);
> 
> I think target_run_apt ought to lose the $timeout parameter.  Anyone
> who calls it with other than the big 3000s timeout might lose, after
> all.

Good point.

FWIW I don't think this patch is actually necessary for this series, it
arose during an early version because I was installing stuff in
ts-build-libvirt, but now everything is done in e.g. ts-build-prep.

I think it's still a step in the direction you wanted wrt sharing
machine though, so I'll keep it in the series next time around too.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.