Open Stack

On 06/23/2014 11:24 AM, Ben Nemec wrote:
> 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. ;-)

But if we had originally thought to use pylockfile except for the bug,
and if oslo.lockutils brings in oslo.config making it not suitable for
general usage - it seems like it would be a good thing for the wider
community if we 'fix' pylockfile and make oslo.lockutils the
oslo-ification of it?

I mean, ultimately like everything else in OpenStack we don't REALLY
want to just have our own set of parallel libs to what the rest of
python uses, do we?

>>
>>
>> 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
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>