Open Stack

On Jun 23, 2014, at 11:30 AM, Monty Taylor <mordred at inaugust.com> wrote:

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

+100

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


-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140623/2496a0ed/attachment.pgp>