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 <jul...@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


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to