[openstack-dev] [oslo] Adopting pylockfile

Doug Hellmann doug.hellmann at dreamhost.com
Mon Jun 23 15:02:36 UTC 2014

On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec <openstack at nemebean.com> wrote:
> Hash: SHA1
> On 06/23/2014 08:41 AM, Julien Danjou wrote:
>> Hi there,
>> We discovered a problem in pylockfile recently, and after
>> discussing with its current maintainer, it appears that more help
>> and workforce would be require:
>> https://github.com/smontanaro/pylockfile/issues/11#issuecomment-45634012
>>  Since we are using it via oslo lockutils module, I proposed to
>> adopt this project under the Oslo program banner. The review to
>> copy the repository to our infrastructure is up at:
>> https://review.openstack.org/#/c/101911/
> We actually don't use this in lockutils - we use our own
> implementation of LockFile because there was some sort of outstanding
> bug in pylockfile that made it not work for us.  The only place I can
> see that we do use that project is in the oslo.db code because we
> didn't want to depend on incubator modules there, but once
> oslo.concurrency graduates we can switch to using our own locking
> implementation again.
> Basically I think this would be duplicating what we're already doing
> in lockutils, so I'm -1 on it.  I'd rather focus on getting
> oslo.concurrency graduated and remove pylockfile from
> global-requirements to make sure no one is using it anymore.

Which makes more sense, continuing to maintain our library or fixing
that bug and maintaining pylockfile? How big is pylockfile compared to
what we have? Does it solve problems our existing locking code doesn't
solve (and that we care about)?

> This also makes me wonder if oslo.concurrency should not be an oslo.*
> library since this functionality is more generally applicable outside
> OpenStack.  Something to discuss anyway.

That makes sense. When I made the list of libraries to release this
time, I called them all "oslo.foo" because I wasn't digging into the
code deep enough to figure out whether they could be something else. I
expected the person managing the spec for the release to do that step,
but I may not have made that clear.

The main thing I would be concerned with about using a non-oslo name
for oslo.concurrency is whether or not it uses another oslo library
like oslo.config. If we can completely avoid those dependencies, then
it should be safe to release it under a name other than


>> Cheers,
>> _______________________________________________ OpenStack-dev
>> mailing list OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> alztUIjHzClZBne0weAe10UzqWGmfSFJKhpThAB3IP9xdS39ZmW4zAGQm8obk4RL
> Qj9nDPt/WRb0kMlWulTckfVR2hWDc0kZ2Y5YBFR0ubWQfNoyh14rF9VEtuVsZOwW
> 1/F60rlXy9iZGC/Mw+XK5ZJhoG6k7EZucDR6y0bfaNLdOWDUeEaqzq1lvfULyaYS
> MZxfEFnsY1GkRxSX4U/SMvu1xV3yTkrbLXmsj3fAJBW4HQfp+9bdAfkz/Z1snYl6
> VtMvfDYChJogq2c7G35RD161nxmMxsOyrLm/YSqc7dPkMytdKD3YXwAuYsiVIJM=
> =YBxv
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list