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
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 @
(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).
On Tue, Aug 12, 2014 at 6:12 AM, Julien Danjou <jul...@danjou.info>
On Mon, Aug 11 2014, Joshua Harlow wrote:
Sounds great, I've been wondering why
(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
several nodes. In that case, having a ZK or memcached backend is
as IPC is good enough.
;; Free Software hacker
OpenStack-dev mailing list