[openstack-dev] [oslo] Adopting pylockfile
openstack at nemebean.com
Mon Jun 23 15:24:02 UTC 2014
On 06/23/2014 10:02 AM, Doug Hellmann wrote:
> On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec <openstack at nemebean.com> wrote:
> 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:
>>>> 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:
> 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)?
It looks to me like pylockfile would provide a subset of the
functionality in lockutils (for example, I don't see anything to replace
the @lock decorator). So I don't think we could just drop lockutils and
switch to it. We'd just be switching out the underlying lock mechanism,
and we know how well that has gone in the past. ;-)
> 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
Oh, that's probably why I didn't suggest this in the first place.
lockutils uses oslo.config, so it does need to be in the oslo namespace.
I don't think we can drop the oslo.config dep, but we might be able to
decouple it like oslo.db did. I think that would be messy though
because Windows is where problems would come up and we don't test
Windows in the gate. :-/
>>>> _______________________________________________ OpenStack-dev
>>>> mailing list OpenStack-dev at lists.openstack.org
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev