Open Stack

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:
>>>>
>>>> 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)?

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
>> oslo.concurrency.

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. :-/

> 
>> Doug
> 
> 
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> _______________________________________________ OpenStack-dev
>>>> mailing list OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
> 
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev