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. ;-) > > > 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
