[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |