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