On Fri, Sep 25, 2015 at 9:56 AM, Curtis Hovey-Canonical < cur...@canonical.com> wrote:
> On Fri, Sep 25, 2015 at 9:15 AM, Tim Van Steenburgh > <tim.van.steenbu...@canonical.com> wrote: > > Hi everyone, > > > > I have a jenkins slave that's running charm and bundle tests on 5 > different > > clouds pretty much all the time. My problem is that tests will randomly > fail > > after hitting this lock timeout. > > Juju QA has pondered deleting any lock more than a minute old every > time we call the client to bootstrap or destroy-environment. > This is a good idea and probably worth doing, although it won't fix our most common failure, where a test run bootstraps successfully, but then fails later when *another* env bootstraps just before the running test tries to execute a juju command. > > > Is the best way around this to have a separate $JUJU_HOME for all my test > > clouds, so that I end up with one lock per cloud? I haven't tried this > yet > > but it seems like the simplest way forward, if it works and is safe (is > > it?). > > Generating separate JUJU_HOMEs will insulate your from bug > https://bugs.launchpad.net/juju-core/+bug/1467331 Thanks, I'm going to try this approach and see what happens. Although, it seems to me that if it's safe to have multiple JUJU_HOMEs, all "doing stuff" concurrently, it would also be possible to have one lock per env, instead of one global lock. Can anyone on the core team explain why there is one global lock? I'm just curious. > > > > -- > Curtis Hovey > Canonical Cloud Development and Operations > http://launchpad.net/~sinzui >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
