Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 07/14/2015 11:58 AM, Luigi Toscano wrote:
On Tuesday 14 of July 2015 10:33:18 Ihar Hrachyshka wrote:
On 07/14/2015 01:46 AM, Perry, Sean wrote:
-Original Message- From: Doug Hellmann
I don't *want* to keep 2.6 support around, and I do understand
that the requirements work will be made easier. I'm just trying
to understand what other impact dropping it will have.
It will break RHEL 5 (maybe early 6 too) and older RH systems.
Ubuntu older than 9 I think (which is beyond unsupported). Not sure
about other Linux dists.
Basically if RHEL 5 is no longer a valid target and we are sure all
of the 6s have updated then let's nuke it from orbit.
I don't believe there was any release of RHEL-OSP that targeted RHEL
5. As for RHEL 6, the last version that got support for it was OSP5
which is based on Icehouse.
Speaking of RDO, there were attempts to get nova pieces of Juno
backported to RHEL 6 (mostly for CERN). Other than that, I don't think
anyone considers to run anything Kilo+ on RHEL 6, and it will probably
fail to work properly since a lot of underlying platform components in
RHEL 6 would be not ready for new features. (RHEL-OSP could
potentially get all the needed pieces in place, but there was a
decision not to go this route and instead require RHEL 7 for anything
Juno+).
Some Sahara plugins (HDP, CDH) supports only CentOS6/RHEL6. In order to
generate images for them, even if diskimage-builder some scripts need to run
on the guest directly. So at least diskimage-builder should keep Python 2.6
support for guests (RHEL6 ships with Python 2.6)
In that case, please comment on
https://review.openstack.org/#/c/201295/
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/14/2015 01:46 AM, Perry, Sean wrote: -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Monday, July 13, 2015 3:41 PM To: openstack-dev Subject: Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master Excerpts from Robert Collins's message of 2015-07-14 09:05:43 +1200: On 14 July 2015 at 02:10, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). Additional detail: - generating 2.6 pins for global requirements requires access to 2.6 where the periodic job runs *and where devs are generating updates*. - so that means docker or lxc or something in both the CI system and widely available for devs. So its a non-trivial impact; we can do it to move things forward, but it would be a lot cheaper not to. I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be made easier. I'm just trying to understand what other impact dropping it will have. It will break RHEL 5 (maybe early 6 too) and older RH systems. Ubuntu older than 9 I think (which is beyond unsupported). Not sure about other Linux dists. Basically if RHEL 5 is no longer a valid target and we are sure all of the 6s have updated then let's nuke it from orbit. I don't believe there was any release of RHEL-OSP that targeted RHEL 5. As for RHEL 6, the last version that got support for it was OSP5 which is based on Icehouse. Speaking of RDO, there were attempts to get nova pieces of Juno backported to RHEL 6 (mostly for CERN). Other than that, I don't think anyone considers to run anything Kilo+ on RHEL 6, and it will probably fail to work properly since a lot of underlying platform components in RHEL 6 would be not ready for new features. (RHEL-OSP could potentially get all the needed pieces in place, but there was a decision not to go this route and instead require RHEL 7 for anything Juno+). Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVpMlOAAoJEC5aWaUY1u57aqMH/jUqVjZeYTFGIG5ncxU62IuU Jenu/c5GaGiwMdU4dDG4x25hH6NRN3vNmbXE6oF5HrkbCq7oqih7IjoTI/3Wfo6U Pwk951VU986duN8syxH+dINWZiOrZ8UNDgO2VI3Tn15TUG/S3eZtMTuM9BHoLn2K cQYlqZrKQnKVK+zNHdZI7X58P728BNeWONUl5ry7mwOZcWDs7PzvsGJ1t8zrDsE4 sGT3QT3x9VCi+tVD17DW7ZuBA+W1oVtNp3RdDkIN5fsaSE0WDZPr9PPW6jIxHNKo BP+GS7GPvqZEOK2A4I1foZg6tpkDYlxQo1D5Pz7Ep/9LIDahvE5EUQHRQoUPVH8= =CuFo -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On Tuesday 14 of July 2015 10:33:18 Ihar Hrachyshka wrote: On 07/14/2015 01:46 AM, Perry, Sean wrote: -Original Message- From: Doug Hellmann I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be made easier. I'm just trying to understand what other impact dropping it will have. It will break RHEL 5 (maybe early 6 too) and older RH systems. Ubuntu older than 9 I think (which is beyond unsupported). Not sure about other Linux dists. Basically if RHEL 5 is no longer a valid target and we are sure all of the 6s have updated then let's nuke it from orbit. I don't believe there was any release of RHEL-OSP that targeted RHEL 5. As for RHEL 6, the last version that got support for it was OSP5 which is based on Icehouse. Speaking of RDO, there were attempts to get nova pieces of Juno backported to RHEL 6 (mostly for CERN). Other than that, I don't think anyone considers to run anything Kilo+ on RHEL 6, and it will probably fail to work properly since a lot of underlying platform components in RHEL 6 would be not ready for new features. (RHEL-OSP could potentially get all the needed pieces in place, but there was a decision not to go this route and instead require RHEL 7 for anything Juno+). Some Sahara plugins (HDP, CDH) supports only CentOS6/RHEL6. In order to generate images for them, even if diskimage-builder some scripts need to run on the guest directly. So at least diskimage-builder should keep Python 2.6 support for guests (RHEL6 ships with Python 2.6) Ciao -- Luigi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/14/2015 01:46 AM, Perry, Sean wrote: -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Monday, July 13, 2015 3:41 PM To: openstack-dev Subject: Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master Excerpts from Robert Collins's message of 2015-07-14 09:05:43 +1200: On 14 July 2015 at 02:10, Jeremy Stanleyfu...@yuggoth.org wrote: On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). Additional detail: - generating 2.6 pins for global requirements requires access to 2.6 where the periodic job runs *and where devs are generating updates*. - so that means docker or lxc or something in both the CI system and widely available for devs. So its a non-trivial impact; we can do it to move things forward, but it would be a lot cheaper not to. I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be made easier. I'm just trying to understand what other impact dropping it will have. It will break RHEL 5 (maybe early 6 too) and older RH systems. Ubuntu older than 9 I think (which is beyond unsupported). Not sure about other Linux dists. Basically if RHEL 5 is no longer a valid target and we are sure all of the 6s have updated then let's nuke it from orbit. I don't believe there was any release of RHEL-OSP that targeted RHEL 5. As for RHEL 6, the last version that got support for it was OSP5 which is based on Icehouse. Speaking of RDO, there were attempts to get nova pieces of Juno backported to RHEL 6 (mostly for CERN). Other than that, I don't think anyone considers to run anything Kilo+ on RHEL 6, and it will probably fail to work properly since a lot of underlying platform components in RHEL 6 would be not ready for new features. (RHEL-OSP could potentially get all the needed pieces in place, but there was a decision not to go this route and instead require RHEL 7 for anything Juno+). Just a side-note, people have gotten kilo+ to run on RHEL6.x using virtualenvs and SCL python2.7 using http://anvil.readthedocs.org/ so it's not out of the realm of possible ;) Not everyone can upgrade to RHEL7.x 'in a jiffy' when u have a large cloud with a ton of RHEL6.x hypervisors that people rely on, eventually it will happen, but not always so quickly ;) Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVpMlOAAoJEC5aWaUY1u57aqMH/jUqVjZeYTFGIG5ncxU62IuU Jenu/c5GaGiwMdU4dDG4x25hH6NRN3vNmbXE6oF5HrkbCq7oqih7IjoTI/3Wfo6U Pwk951VU986duN8syxH+dINWZiOrZ8UNDgO2VI3Tn15TUG/S3eZtMTuM9BHoLn2K cQYlqZrKQnKVK+zNHdZI7X58P728BNeWONUl5ry7mwOZcWDs7PzvsGJ1t8zrDsE4 sGT3QT3x9VCi+tVD17DW7ZuBA+W1oVtNp3RdDkIN5fsaSE0WDZPr9PPW6jIxHNKo BP+GS7GPvqZEOK2A4I1foZg6tpkDYlxQo1D5Pz7Ep/9LIDahvE5EUQHRQoUPVH8= =CuFo -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Rob, Please see: https://etherpad.openstack.org/p/juno-cross-project-future-of-python -- dims On Mon, Jul 13, 2015 at 5:39 AM, Robert Collins robe...@robertcollins.net wrote: On 13 July 2015 at 20:08, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/13/2015 03:29 AM, Robert Collins wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Huh. I wasn't part of that discussion... does anyone have a link to why we're supporting a release upstream have completely moved on from 2 years ago? Surely folk wanting to use clients from Python2.6 could just use our older API clients, which due to good backwards compat should still work. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 13/07/2015 13:57, Jeremy Stanley wrote: people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Hopefully, some Linux distro package python-novaclient and so user don't have to guess the version compatible with their OS. https://packages.debian.org/jessie/python-novaclient http://packages.ubuntu.com/fr/precise/python/python-novaclient https://admin.fedoraproject.org/pkgdb/package/python-novaclient/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html/Command-Line_Interface_Reference_Guide/install_clients.html etc. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 13 July 2015 at 20:08, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/13/2015 03:29 AM, Robert Collins wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Huh. I wasn't part of that discussion... does anyone have a link to why we're supporting a release upstream have completely moved on from 2 years ago? Surely folk wanting to use clients from Python2.6 could just use our older API clients, which due to good backwards compat should still work. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 2015-07-13 06:03:56 -0400 (-0400), Davanum Srinivas wrote: Please see: https://etherpad.openstack.org/p/juno-cross-project-future-of-python That decision happened at a time when there were no stable branches of clients/libs and no expectation of their existence. Since then the situation has changed, and it's worth revisiting that choice. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Excerpts from Jeremy Stanley's message of 2015-07-13 11:57:35 +: On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Yes, that's my recollection, too. I'm also a bit worried about the PyPI situation, since pip doesn't automatically detect that a version of a package is incompatible with the current version of python. The etherpad Dims linked to [1] proposes looking at the PyPI stats for client downloads. If those look relatively low, I would feel more confident in dropping 2.6 support in the master branch of the clients, with major version updates to indicate that. On the other hand, how much longer will we be supporting Juno? A matter of months, right? Doug [1] https://etherpad.openstack.org/p/juno-cross-project-future-of-python __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 7/13/2015 6:57 AM, Jeremy Stanley wrote: On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Taking python-novaclient as an example, there is still a gating py26 job on that project, so it still works. If/when we drop py26 support for a client, we could tag that commit and then people wanting to use the client on py26 could build a package from before that tag and then lay down whatever other patches they needed. Tempest is already sort of doing some things like this with tagging milestones due to the branchless nature of Tempest, so it seems the same idea could be carried over to the clients in cases like this. -- Thanks, Matt Riedemann __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Excerpts from Matt Riedemann's message of 2015-07-13 08:52:37 -0500: On 7/13/2015 6:57 AM, Jeremy Stanley wrote: On 2015-07-13 10:08:16 +0200 (+0200), Ihar Hrachyshka wrote: clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Yes, that decision was made at a time when our server projects had stable branches, but our clients and shared libraries did not. My recollection is that server projects only was a proxy for only projects with stable branches. Now that we have stable branches of, say, python-novaclient where we can backport juno-relevant security fixes, people on 2.6-only platforms who want to install and run python-novaclient from PyPI can use the stable/juno version (though I'll admit that finding which version works with 2.6 may be a tricky proposition for a consumer who is unaware of this situation). Taking python-novaclient as an example, there is still a gating py26 job on that project, so it still works. If/when we drop py26 support for a client, we could tag that commit and then people wanting to use the client on py26 could build a package from before that tag and then lay down whatever other patches they needed. Tempest is already sort of doing some things like this with tagging milestones due to the branchless nature of Tempest, so it seems the same idea could be carried over to the clients in cases like this. We'll want to tag final compatible releases before removing the job, and then after that add a patch removing the trove classifier. The next release after removing the trove classifier should increment the major version number, indicating a drop in expected compatibility. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
On 14 July 2015 at 02:10, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). Additional detail: - generating 2.6 pins for global requirements requires access to 2.6 where the periodic job runs *and where devs are generating updates*. - so that means docker or lxc or something in both the CI system and widely available for devs. So its a non-trivial impact; we can do it to move things forward, but it would be a lot cheaper not to. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
-Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Monday, July 13, 2015 3:41 PM To: openstack-dev Subject: Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master Excerpts from Robert Collins's message of 2015-07-14 09:05:43 +1200: On 14 July 2015 at 02:10, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). Additional detail: - generating 2.6 pins for global requirements requires access to 2.6 where the periodic job runs *and where devs are generating updates*. - so that means docker or lxc or something in both the CI system and widely available for devs. So its a non-trivial impact; we can do it to move things forward, but it would be a lot cheaper not to. I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be made easier. I'm just trying to understand what other impact dropping it will have. It will break RHEL 5 (maybe early 6 too) and older RH systems. Ubuntu older than 9 I think (which is beyond unsupported). Not sure about other Linux dists. Basically if RHEL 5 is no longer a valid target and we are sure all of the 6s have updated then let's nuke it from orbit. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
Excerpts from Robert Collins's message of 2015-07-14 09:05:43 +1200: On 14 July 2015 at 02:10, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-07-13 09:39:36 -0400 (-0400), Doug Hellmann wrote: [...] On the other hand, how much longer will we be supporting Juno? A matter of months, right? The reason it's being brought up again at this point is to ask whether it's more important that we keep master clients/libs working with 2.6 for several more months, or be able to push forward with our constraints overhaul between now and then. I'll be hard to have the necessary tooling in place before the liberty release if we can't actually use it before then (since that's roughly when juno EOL is scheduled). Additional detail: - generating 2.6 pins for global requirements requires access to 2.6 where the periodic job runs *and where devs are generating updates*. - so that means docker or lxc or something in both the CI system and widely available for devs. So its a non-trivial impact; we can do it to move things forward, but it would be a lot cheaper not to. I don't *want* to keep 2.6 support around, and I do understand that the requirements work will be made easier. I'm just trying to understand what other impact dropping it will have. Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/13/2015 03:29 AM, Robert Collins wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. clients and oslo libraries still maintain their py26 for a reason: decision to drop py26 was for server projects only. Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVo3HtAAoJEC5aWaUY1u577J8IAIXGGn7TwU4HP8PhJrh1yYwF WSotNA4qWk8GXd16sDxdMG0TqLe4+Ui4As9VDGn6AAwBKQ4IOJnkMZPHPdEZ0SAP fUiaS05LfmKkz8vrn9F2dQVt32XMOLelaznJ7Y+fvR6ULWJHnMq42JPXq3+NF56F dSTEB1WR4jgyo2l38VjuMKGivs8Nki92clAPe4D/bd8pgsng2MKTMwtNDUBH0GNy hflN+zi7wFD5XEvfTgYGbcPqHVUxtJaqwXFjC0jzpMQ9Z9LrelfuY5dwn65RHWUR isZUM/zfZ9ucXDuBBEwtw8eM6LFihuvMOLd6ol37TsxJSWiFnAuaccSVhKuljvA= =Mc+Q -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Time to remove Python2.6 jobs from master
This includes for client libraries too? --John On Jul 12, 2015, at 6:29 PM, Robert Collins robe...@robertcollins.net wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev signature.asc Description: Message signed with OpenPGP using GPGMail __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Time to remove Python2.6 jobs from master
So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
