The code does just hold the lock for the duration of the read or write. Since it is possible to have multiple environments sharing a server, and the server data, the access to that data is synchronized.
There *shouldn't* be a case where the lock is held but not released. The lock file itself should hold some information about who locked it and why. Tim On 26/09/15 18:43, John Meinel wrote: > I don't know the concrete details here, but I do believe there are a few > files that are shared in one JUJU_HOME. There is only one > environments.yaml and the new multi-environment code means there is > another shared file that holds the list of known servers and environments. > I would hope that the code would not hold the lock for the lifetime of > the process but only do a "grab the lock, read, update, write, release > the lock". But I don't know that code, so there might have been some > other thoughts there. > > John > =:-> > > On Sep 25, 2015 5:44 PM, "Tim Van Steenburgh" > <[email protected] > <mailto:[email protected]>> wrote: > > > On Fri, Sep 25, 2015 at 9:56 AM, Curtis Hovey-Canonical > <[email protected] <mailto:[email protected]>> wrote: > > On Fri, Sep 25, 2015 at 9:15 AM, Tim Van Steenburgh > <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > > > -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
