Re: [openstack-dev] [oslo] Adopting pylockfile
Julien, Thanks. +1 from me. On Mon, Jun 23, 2014 at 9:41 AM, Julien Danjou jul...@danjou.info 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/ Cheers, -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adopting pylockfile
Could you fill out a spec using the graduation template so we can identify the various contacts we need (maintainers, security, etc.)? We can use the spec as a place for the team to vote on whether or not they agree to adopt the library. Doug On Mon, Jun 23, 2014 at 9:41 AM, Julien Danjou jul...@danjou.info 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/ Cheers, -- Julien Danjou ;; Free Software hacker ;; http://julien.danjou.info ___ 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
Re: [openstack-dev] [oslo] Adopting pylockfile
On Mon, Jun 23 2014, Doug Hellmann wrote: Could you fill out a spec using the graduation template so we can identify the various contacts we need (maintainers, security, etc.)? We can use the spec as a place for the team to vote on whether or not they agree to adopt the library. Ok, but I raised my fist reading your message because of the bureaucracy OpenStack is becoming. :-) -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adopting pylockfile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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. Cheers, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqDvqAAoJEDehGd0Fy7uqjOIH/RyvsUstB473A8NzDBEUyLYp alztUIjHzClZBne0weAe10UzqWGmfSFJKhpThAB3IP9xdS39ZmW4zAGQm8obk4RL Qj9nDPt/WRb0kMlWulTckfVR2hWDc0kZ2Y5YBFR0ubWQfNoyh14rF9VEtuVsZOwW 1/F60rlXy9iZGC/Mw+XK5ZJhoG6k7EZucDR6y0bfaNLdOWDUeEaqzq1lvfULyaYS MZxfEFnsY1GkRxSX4U/SMvu1xV3yTkrbLXmsj3fAJBW4HQfp+9bdAfkz/Z1snYl6 VtMvfDYChJogq2c7G35RD161nxmMxsOyrLm/YSqc7dPkMytdKD3YXwAuYsiVIJM= =YBxv -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adopting pylockfile
On Mon, Jun 23 2014, Ben Nemec wrote: 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. Oh you're right, I got confused while chasing the bug. 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. That'd work for me. 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. Agreed. I also think there is some potential relation with tooz, as it provides locking on a distributed fashion. So it can be seen as a complement of tooz I'd say. Maybe something to think about. -- Julien Danjou -- Free Software hacker -- http://julien.danjou.info signature.asc Description: PGP signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adopting pylockfile
On Mon, Jun 23, 2014 at 10:38 AM, Ben Nemec openst...@nemebean.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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)? 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. Doug Cheers, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTqDvqAAoJEDehGd0Fy7uqjOIH/RyvsUstB473A8NzDBEUyLYp alztUIjHzClZBne0weAe10UzqWGmfSFJKhpThAB3IP9xdS39ZmW4zAGQm8obk4RL Qj9nDPt/WRb0kMlWulTckfVR2hWDc0kZ2Y5YBFR0ubWQfNoyh14rF9VEtuVsZOwW 1/F60rlXy9iZGC/Mw+XK5ZJhoG6k7EZucDR6y0bfaNLdOWDUeEaqzq1lvfULyaYS MZxfEFnsY1GkRxSX4U/SMvu1xV3yTkrbLXmsj3fAJBW4HQfp+9bdAfkz/Z1snYl6 VtMvfDYChJogq2c7G35RD161nxmMxsOyrLm/YSqc7dPkMytdKD3YXwAuYsiVIJM= =YBxv -END PGP SIGNATURE- ___ 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
Re: [openstack-dev] [oslo] Adopting pylockfile
On Mon, Jun 23, 2014 at 10:37 AM, Skip Montanaro s...@pobox.com wrote: On Mon, Jun 23, 2014 at 9:30 AM, Doug Hellmann doug.hellm...@dreamhost.com wrote: Could you fill out a spec using the graduation template so we can identify the various contacts we need (maintainers, security, etc.)? We can use the spec as a place for the team to vote on whether or not they agree to adopt the library. Who is you in this context? Me? Or someone else? If it's me, I have no idea what you are referring to. Sorry, Skip, I didn't even notice you were copied on that email. The request was for Julien, so you don't need to do anything. We have a process that involves writing up a formal proposal and submitting it to a documentation repository, and that process will give me a place to record the votes of the Oslo team on whether or not they are willing to take over maintenance. I don't expect an issue, but I'd like to have the votes on record for posterity. Doug Skip ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adopting pylockfile
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
Re: [openstack-dev] [oslo] Adopting pylockfile
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
Re: [openstack-dev] [oslo] Adopting pylockfile
On Jun 23, 2014, at 11:30 AM, Monty Taylor mord...@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 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? +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@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 - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo] Adopting pylockfile
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. 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
Re: [openstack-dev] [oslo] Adopting pylockfile
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 ___
