Open Stack

Sure, thats great as to why a feature like it might exist (and I think 
such a feature is great to have, for cases when a bigger *distributed* 
system isn't desired).

Just the one there taken from lockutils has some issues that IMHO I 
think tooz would be better to avoid for the time-being (until 
pylockfile is updated to have a more reliable implementation). Some of 
the current issues I can think of off the top of my head:

1. https://bugs.launchpad.net/oslo/+bug/1327946 (this means the usage 
in tooz will be similarily not resistant to program termination, which 
in a library like tooz seems more severe, since tooz has no way of 
knowing how it, as a library, will be used). With this bug future 
acquisition after *forceful* program termination will result in the 
acquire() method not working for the same IPClock name (ever).

2. The double API, tooz configures lockutils one way, someone else can 
go under tooz and use `set_defaults()` (or other ways that I'm not 
aware of that can be used to configure oslo.config) and expect that the 
settings they will have set will actually do something, when in fact 
they will not (or will they???). This seems like a bad point of 
confusion for an API to have, where some of its API is from 
methods/functions... and some is from oslo.config...

3. Bringing in oslo.config as a dependency (tooz isn't configured via 
oslo.config but now it has code that looks like it is configured this 
via it). What happens if the parts of tooz now are set by oslo.config 
and some parts aren't? This seems bad from a user experience (where the 
user is the library user) point of view and a testability point of view 
(and probably other points of view that I can't think of), when there 
are new options that can be set via a *secret* API that now affect how 
tooz works...

4. What happens with windows here (since tooz is a library it's hard to 
predict how it will be used, unless windows is not supported)? Windows 
will resort back to using a filelock, which will default to using 
whatever oslo.config file path was set for tooz, which again goes back 
to #2 and #3 and having 2 apis, one public and one *secret* that can 
affect how tooz operates... In this case it seems 
`default=os.environ.get("TOOZ_LOCK_PATH")` will be used, when that's 
not set tooz now blows up with a weird configuration error @ 
https://github.com/stackforge/tooz/blob/master/tooz/openstack/common/lockutils.py#L222 
(this all seems bad for users of tooz)...

What do u think about waiting until pylockfile is ready and avoiding 
1-4 from above? At least if taskflow uses tooz I surely don't want 
taskflow to have to deal with #1-4 (which it will inherit from tooz if 
taskflow starts to use tooz by the very nature of taskflow using tooz 
as a library).

Thoughts?

-Josh

On Tue, Aug 12, 2014 at 6:12 AM, Julien Danjou <julien at danjou.info> 
wrote:
> On Mon, Aug 11 2014, Joshua Harlow wrote:
> 
>>  Sounds great, I've been wondering why
>>  https://github.com/stackforge/tooz/commit/f3e11e40f9871f8328 
>> happened/merged
>>  (maybe it should be changed?).
> 
> For the simple reason that there's people wanting to use a lock
> distributed against several processes without being distributed 
> against
> several nodes. In that case, having a ZK or memcached backend is 
> useless
> as IPC is good enough.
> 
> -- 
> Julien Danjou
> ;; Free Software hacker
> ;; http://julien.danjou.info