ERROR cannot read info: lock timeout exceeded

[Tim Van Steenburgh]

On Fri, Sep 25, 2015 at 9:56 AM, Curtis Hovey-Canonical <
curtis at canonical.com> wrote:

> On Fri, Sep 25, 2015 at 9:15 AM, Tim Van Steenburgh
> <tim.van.steenburgh at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20150925/13fe57cd/attachment.html>