Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote: > Source: openvswitch > Version: 2.3.0+git20140819-4 > Severity: normal > > Hi, > > OpenStack Neutron currently has: > > ovs>=2.5.0;python_version=='2.7' # Apache-2.0 > ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 > > in its requirements.txt. Please package this at least to Debian Experimental, > so that I can package Neutron Newton Beta 1. I uploaded openvswitch_2.5.1~pre+git20160626-1 a couple of hours ago. It's going through NEW processing. I suspect that it will take a couple of trial uploads to get the tests to pass reliably and on all architectures. I'm going to be traveling Monday through Thursday, with limited time for computers, so absent helpful NMUs (which are welcome) there will probably be at least limited breakage until Friday. I honestly meant to upload this to experimental for the first one or two tries but screwed up so it's destined for unstable.
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On 06/10/2016 10:38 PM, Ben Pfaff wrote: > On Thu, Jun 09, 2016 at 04:07:13AM -0400, Russell Bryant wrote: >> I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start running >> tests using the version of the Python library that includes Python 3. I >> followed some python packaging / pypi versioning guidelines to pick that >> number. It indicates that it's a dev snapshot of what will eventually >> (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find that >> appropriate to use, as it isn't 2.5 at all. > > The .90 suffix is supposed to indicate that it's much greater than 2.5, > but less than 2.6. > > dpkg considers 2.6.0.dev1 to be greater than 2.6.0: > $ if dpkg --compare-versions 2.6.0.dev1 gt 2.6.0; then echo greater; else > echo less; fi > greater > so it seems like a poor choice for anything in Debian. That's ok though. There's nothing you can do with the Python version numbers which are kind of incompatible with what we do in Debian (the char ~ is forbidden in PyPi). So the way to do it in Debian is to rename 2.6.0.dev1 as 2.6.0~dev1. Cheers, Thomas Goirand (zigo)
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Fri, Jun 10, 2016 at 04:42:11PM -0400, Russell Bryant wrote: > On Fri, Jun 10, 2016 at 4:38 PM, Ben Pfaff wrote: > > > On Thu, Jun 09, 2016 at 04:07:13AM -0400, Russell Bryant wrote: > > > I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start > > running > > > tests using the version of the Python library that includes Python 3. I > > > followed some python packaging / pypi versioning guidelines to pick that > > > number. It indicates that it's a dev snapshot of what will eventually > > > (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find > > that > > > appropriate to use, as it isn't 2.5 at all. > > > > The .90 suffix is supposed to indicate that it's much greater than 2.5, > > but less than 2.6. > > > > dpkg considers 2.6.0.dev1 to be greater than 2.6.0: > > $ if dpkg --compare-versions 2.6.0.dev1 gt 2.6.0; then echo greater; > > else echo less; fi > > greater > > so it seems like a poor choice for anything in Debian. > > > > (I guess you must know the rules for Fedora, so presumably this works > > there? Those rules seem to involve separate Version and Release fields > > and I really don't understand them. On the other hand, according to > > https://www.redhat.com/archives/rpm-list/2005-January/msg5.html, > > developers are discouraged from understanding details of the version > > numbering rules for RPM...) > > This was just a dev snapshot for PyPI (Python Package Index), not intended > to be packaged anywhere else. > > https://www.python.org/dev/peps/pep-0440/ OK, great, I didn't realize that.
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Fri, Jun 10, 2016 at 4:38 PM, Ben Pfaff wrote: > On Thu, Jun 09, 2016 at 04:07:13AM -0400, Russell Bryant wrote: > > I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start > running > > tests using the version of the Python library that includes Python 3. I > > followed some python packaging / pypi versioning guidelines to pick that > > number. It indicates that it's a dev snapshot of what will eventually > > (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find > that > > appropriate to use, as it isn't 2.5 at all. > > The .90 suffix is supposed to indicate that it's much greater than 2.5, > but less than 2.6. > > dpkg considers 2.6.0.dev1 to be greater than 2.6.0: > $ if dpkg --compare-versions 2.6.0.dev1 gt 2.6.0; then echo greater; > else echo less; fi > greater > so it seems like a poor choice for anything in Debian. > > (I guess you must know the rules for Fedora, so presumably this works > there? Those rules seem to involve separate Version and Release fields > and I really don't understand them. On the other hand, according to > https://www.redhat.com/archives/rpm-list/2005-January/msg5.html, > developers are discouraged from understanding details of the version > numbering rules for RPM...) > This was just a dev snapshot for PyPI (Python Package Index), not intended to be packaged anywhere else. https://www.python.org/dev/peps/pep-0440/ -- Russell Bryant
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 09, 2016 at 04:07:13AM -0400, Russell Bryant wrote: > I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start running > tests using the version of the Python library that includes Python 3. I > followed some python packaging / pypi versioning guidelines to pick that > number. It indicates that it's a dev snapshot of what will eventually > (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find that > appropriate to use, as it isn't 2.5 at all. The .90 suffix is supposed to indicate that it's much greater than 2.5, but less than 2.6. dpkg considers 2.6.0.dev1 to be greater than 2.6.0: $ if dpkg --compare-versions 2.6.0.dev1 gt 2.6.0; then echo greater; else echo less; fi greater so it seems like a poor choice for anything in Debian. (I guess you must know the rules for Fedora, so presumably this works there? Those rules seem to involve separate Version and Release fields and I really don't understand them. On the other hand, according to https://www.redhat.com/archives/rpm-list/2005-January/msg5.html, developers are discouraged from understanding details of the version numbering rules for RPM...)
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 9, 2016 at 11:04 PM, Joe Stringer wrote: > On 9 June 2016 at 08:50, Terry Wilson wrote: > > On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote: > >> The real solution to making this less awkward would be to split the > Python > >> library out of the OVS git tree so that it can be released > independently of > >> OVS itself. That way a proper verison could be released that includes > >> Python 3 support. > > > > This would be very nice. There are some challenges to overcome. The > > testing infrastructure between the Python and C implementations is > > shared. Out of tree it becomes more a bit more difficult to make sure > > that they stay in sync both feature and compatibility-wise. My gut > > feeling is that it would still be worth the work, though. There's no > > good reason for releases of the Python library to be tied OVS > > releases. > > Setting aside the python3 compatibility issues, the typical number of > commits to this library between releases is pretty small (<10). They > seem to be largely independent of other changes in the OVS tree, but > occasionally they are coupled to other changes. > > Is the proposal really fixing an ongoing issue or just a one-off? It > seems like a lot of effort unless the pace of development on this > library significantly increases and users really need a more frequent > release cycle (for example, because they're releasing versions of > their software more regularly than the OVS and need the latest and > greatest python-ovs). My impression was roughly that it's a fairly new, but an increasing issue. The OpenStack Neutron plugin for OVS and now OVN make heavy use of the library. The OVN Kubernetes integration (CNI plugin) also uses this library. I would expect all of this new heavy usage to lead to increased developement in the library. Availability of bug fixes has been the most significant pain point in the psat. That could be addressed by making more frequent point releases from OVS release branches. If we add features, they're really supposed to be in a proper release before we can use them in OpenStack. It would be nice to have the option to accelerate it. -- Russell Bryant
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 9, 2016 at 10:04 PM, Joe Stringer wrote: >> On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote: >>> The real solution to making this less awkward would be to split the Python >>> library out of the OVS git tree so that it can be released independently of >>> OVS itself. That way a proper verison could be released that includes >>> Python 3 support. >> >> This would be very nice. There are some challenges to overcome. The >> testing infrastructure between the Python and C implementations is >> shared. Out of tree it becomes more a bit more difficult to make sure >> that they stay in sync both feature and compatibility-wise. My gut >> feeling is that it would still be worth the work, though. There's no >> good reason for releases of the Python library to be tied OVS >> releases. > > Setting aside the python3 compatibility issues, the typical number of > commits to this library between releases is pretty small (<10). They > seem to be largely independent of other changes in the OVS tree, but > occasionally they are coupled to other changes. > > Is the proposal really fixing an ongoing issue or just a one-off? It > seems like a lot of effort unless the pace of development on this > library significantly increases and users really need a more frequent > release cycle (for example, because they're releasing versions of > their software more regularly than the OVS and need the latest and > greatest python-ovs). Any python patch I've done is something coming from want to use this is neutron right now: dding the event hook, JSON speedups, etc. I'd also like to add indexing for index columns. None of the changes have had anything to do with what version OVS is. We could backport features/improvements in the Python lib. But then we'd end up with essentially the exact same code in each branch so 2.5.1 is the same code as 2.6.1 and both run fine with OVS 2.4.0. :p It might also be beneficial to have different (or just additional) committers for the Python library. You don't want me touching the openflow code (yet!), but I could certainly handle the Python lib for instance. :) Terry
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On 9 June 2016 at 08:50, Terry Wilson wrote: > On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote: >> The real solution to making this less awkward would be to split the Python >> library out of the OVS git tree so that it can be released independently of >> OVS itself. That way a proper verison could be released that includes >> Python 3 support. > > This would be very nice. There are some challenges to overcome. The > testing infrastructure between the Python and C implementations is > shared. Out of tree it becomes more a bit more difficult to make sure > that they stay in sync both feature and compatibility-wise. My gut > feeling is that it would still be worth the work, though. There's no > good reason for releases of the Python library to be tied OVS > releases. Setting aside the python3 compatibility issues, the typical number of commits to this library between releases is pretty small (<10). They seem to be largely independent of other changes in the OVS tree, but occasionally they are coupled to other changes. Is the proposal really fixing an ongoing issue or just a one-off? It seems like a lot of effort unless the pace of development on this library significantly increases and users really need a more frequent release cycle (for example, because they're releasing versions of their software more regularly than the OVS and need the latest and greatest python-ovs).
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 9, 2016 at 11:50 AM, Terry Wilson wrote: > On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote: > > The real solution to making this less awkward would be to split the > Python > > library out of the OVS git tree so that it can be released independently > of > > OVS itself. That way a proper verison could be released that includes > > Python 3 support. > > This would be very nice. There are some challenges to overcome. The > testing infrastructure between the Python and C implementations is > shared. Out of tree it becomes more a bit more difficult to make sure > that they stay in sync both feature and compatibility-wise. My gut > feeling is that it would still be worth the work, though. There's no > good reason for releases of the Python library to be tied OVS > releases. The next step in turning this into a real proposal would be to prototype the split to show what the two repos would look like after the split. It should also document the impact on developers who need to change both, as well as people working on just ovs (as the build system uses the python lib). To be clear, even though I think this is the "right" thing to do, I don't expect I will do the work any time soon. -- Russell Bryant
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 9, 2016 at 3:07 AM, Russell Bryant wrote: > The real solution to making this less awkward would be to split the Python > library out of the OVS git tree so that it can be released independently of > OVS itself. That way a proper verison could be released that includes > Python 3 support. This would be very nice. There are some challenges to overcome. The testing infrastructure between the Python and C implementations is shared. Out of tree it becomes more a bit more difficult to make sure that they stay in sync both feature and compatibility-wise. My gut feeling is that it would still be worth the work, though. There's no good reason for releases of the Python library to be tied OVS releases. Terry
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On 06/09/2016 10:07 AM, Russell Bryant wrote: > otherwiseguy is Terry Wilson, CC'd, but this one is on me. > > I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start > running tests using the version of the Python library that includes > Python 3. I followed some python packaging / pypi versioning guidelines > to pick that number. It indicates that it's a dev snapshot of what will > eventually (presumably) be 2.6.0. I know OVS generates 2.5.90, but I > don't find that appropriate to use, as it isn't 2.5 at all. > > Regarding the debian issue, I don't see a need to package anything new > beyond 2.5.x. It just won't include Python 3 support yet. > > The real solution to making this less awkward would be to split the > Python library out of the OVS git tree so that it can be released > independently of OVS itself. That way a proper verison could be > released that includes Python 3 support. > > -- > Russell Bryant I'd very much welcome such a move, and could more easily contribute to the python module packaging (while OVS itself is a bit complicated, and I prefer Ben to handle it). Cheers, Thomas Goirand (zigo)
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On Wed, Jun 8, 2016 at 10:35 PM, Joe Stringer wrote: > On 8 June 2016 at 16:40, Ben Pfaff wrote: > > On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote: > >> Source: openvswitch > >> Version: 2.3.0+git20140819-4 > >> Severity: normal > >> > >> Hi, > >> > >> OpenStack Neutron currently has: > >> > >> ovs>=2.5.0;python_version=='2.7' # Apache-2.0 > >> ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 > >> > >> in its requirements.txt. Please package this at least to Debian > Experimental, > >> so that I can package Neutron Newton Beta 1. > > > > I can package 2.5.x, though there are reports that there's one testsuite > > failure on big-endian architectures. > > > > OVS 2.6.0 doesn't exist yet, so it can't be packaged. When Neutron asks > > for 2.6.0 what does it mean? > > It would appear that someone has uploaded an OVS 2.5.90 development > version of the OVS python libraries to pypi as 2.6.0.dev1: > https://pypi.python.org/pypi/ovs/2.6.0.dev1 > > This probably has the latest python3 fixes that were applied since OVS > 2.5, so is required if someone wants to run neutron under python3. > > Russell, do you know much about this? I'd CC otherwiseguy, but I don't > know who that is off-hand. > otherwiseguy is Terry Wilson, CC'd, but this one is on me. I uploaded "2.6.0.dev1". This was to enable OpenStack CI to start running tests using the version of the Python library that includes Python 3. I followed some python packaging / pypi versioning guidelines to pick that number. It indicates that it's a dev snapshot of what will eventually (presumably) be 2.6.0. I know OVS generates 2.5.90, but I don't find that appropriate to use, as it isn't 2.5 at all. Regarding the debian issue, I don't see a need to package anything new beyond 2.5.x. It just won't include Python 3 support yet. The real solution to making this less awkward would be to split the Python library out of the OVS git tree so that it can be released independently of OVS itself. That way a proper verison could be released that includes Python 3 support. -- Russell Bryant
Bug#826780: [ovs-dev] Bug#826780: Please package OVS >= 2.6.0.dev1
On 8 June 2016 at 16:40, Ben Pfaff wrote: > On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote: >> Source: openvswitch >> Version: 2.3.0+git20140819-4 >> Severity: normal >> >> Hi, >> >> OpenStack Neutron currently has: >> >> ovs>=2.5.0;python_version=='2.7' # Apache-2.0 >> ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 >> >> in its requirements.txt. Please package this at least to Debian Experimental, >> so that I can package Neutron Newton Beta 1. > > I can package 2.5.x, though there are reports that there's one testsuite > failure on big-endian architectures. > > OVS 2.6.0 doesn't exist yet, so it can't be packaged. When Neutron asks > for 2.6.0 what does it mean? It would appear that someone has uploaded an OVS 2.5.90 development version of the OVS python libraries to pypi as 2.6.0.dev1: https://pypi.python.org/pypi/ovs/2.6.0.dev1 This probably has the latest python3 fixes that were applied since OVS 2.5, so is required if someone wants to run neutron under python3. Russell, do you know much about this? I'd CC otherwiseguy, but I don't know who that is off-hand.
Bug#826780: Please package OVS >= 2.6.0.dev1
On Thu, Jun 09, 2016 at 01:23:12AM +0200, Thomas Goirand wrote: > Source: openvswitch > Version: 2.3.0+git20140819-4 > Severity: normal > > Hi, > > OpenStack Neutron currently has: > > ovs>=2.5.0;python_version=='2.7' # Apache-2.0 > ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 > > in its requirements.txt. Please package this at least to Debian Experimental, > so that I can package Neutron Newton Beta 1. I can package 2.5.x, though there are reports that there's one testsuite failure on big-endian architectures. OVS 2.6.0 doesn't exist yet, so it can't be packaged. When Neutron asks for 2.6.0 what does it mean?
Bug#826780: Please package OVS >= 2.6.0.dev1
Source: openvswitch Version: 2.3.0+git20140819-4 Severity: normal Hi, OpenStack Neutron currently has: ovs>=2.5.0;python_version=='2.7' # Apache-2.0 ovs>=2.6.0.dev1;python_version>='3.4' # Apache-2.0 in its requirements.txt. Please package this at least to Debian Experimental, so that I can package Neutron Newton Beta 1. Cheers, Thomas Goirand (zigo)
