On Mon, Jun 23, 2014 at 12:42 PM, Ben Nemec <openst...@nemebean.com> wrote: > On 06/23/2014 10:30 AM, Monty Taylor 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 <openst...@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? > > Fair point. I guess I've just been scarred by the fact that every > single time we've tried to change the underlying lock mechanics in > lockutils we've found some edge case that gets broken. > > But that said, we could limit the changes to lockutils by simply > contributing our lockfile code as an alternative implementation in > pylockfile (it looks like there are already several options there) and > using it from there instead. Then it's more of a refactoring with the > side benefit that anyone else can use the code too, and we have the > option of using other pylockfile implementations if need be. I could > get behind that, so consider my objection to adopting this withdrawn.
+1 > >> >>>> >>>> >>>> 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@lists.openstack.org >>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>>>> >>>> >>>>> >>>>> _______________________________________________ >>>>> OpenStack-dev mailing list >>>>> OpenStack-dev@lists.openstack.org >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
