settingsLogin | Registersettings

[openstack-dev] [all] Python 2.6 should rise from the dead

0 votes

Hi all,
As you may know, support of Python 2.6 was dropped this month from most of
OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.

I'm ok with dropping Python 2.6 support from the master(Mitaka), but what
about stable/kilo and stable/liberty ? Kilo and Liberty were released with
Python 2.6 support and most of projects have py26 classifiers there.
Without py26 jobs in stable branches, it is hard to backport any changes.
Also, requirements for stable/liberty do not contain upper caps for
python-clients and oslo. libraries, so most of projects already have
broken py26 support in Liberty.

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Dec 16, 2015 in openstack-dev by Andrey_Kurilin (3,820 points)   2 4

5 Responses

0 votes

On 2015-12-16 12:33, Andrey Kurilin wrote:
Hi all,
As you may know, support of Python 2.6 was dropped this month from most
of OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.

I'm ok with dropping Python 2.6 support from the master(Mitaka), but
what about stable/kilo and stable/liberty ? Kilo and Liberty were
released with Python 2.6 support and most of projects have py26
classifiers there. Without py26 jobs in stable branches, it is hard to
backport any changes.

Kilo and liberty was not released and neither tested on our server
projects for Python 2.6. If it had py26 classifiers, that was an error.

It was tested only on the client projects so that new python client
libraries could connect to an older installation.

Andreas

Also, requirements for stable/liberty do not contain upper caps for
python-clients and oslo. libraries, so most of projects already have
broken py26 support in Liberty.

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 16, 2015 by Andreas_Jaeger (17,140 points)   2 3 4
0 votes

If it had py26 classifiers, that was an error.

The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizon - stable/kilo, stable/liberty
astara-neutron - stable/kilo, stable/liberty
bifrost - stable/liberty
ceilometermiddleware - stable/kilo, stable/liberty
cloudkitty-dashboard - stable/kilo
compute-hyperv - stable/kilo, stable/liberty
congress - stable/kilo, stable/liberty
debtcollector - stable/kilo, stable/liberty
designate - stable/kilo, stable/liberty
designate-dashboard - stable/liberty
glance_store - stable/kilo
group-based-policy - stable/kilo
group-based-policy-automation - stable/kilo
group-based-policy-ui - stable/kilo
instack-undercloud - stable/liberty
keystoneauth - stable/liberty
keystonemiddleware - stable/kilo
magnum - stable/kilo, stable/liberty
magnum-ui - stable/liberty
manila-ui - stable/kilo, stable/liberty
mox3 - stable/liberty
networking-bagpipe - stable/kilo, stable/liberty
networking-bgpvpn - stable/kilo, stable/liberty
networking-hyperv - stable/kilo, stable/liberty
networking-infoblox - stable/liberty
networking-l2gw - stable/kilo, stable/liberty
networking-nec - stable/kilo
networking-ovs-dpdk - stable/kilo, stable/liberty
networking-plumgrid - stable/kilo, stable/liberty
networking-vsphere - stable/kilo, stable/liberty
nova-docker - stable/kilo, stable/liberty
nova-solver-scheduler - stable/kilo
os-brick - stable/liberty
os-client-config - stable/liberty
oslo-incubator - stable/kilo
oslo.cache - stable/liberty
oslo.concurrency - stable/kilo, stable/liberty
oslo.config - stable/kilo, stable/liberty
oslo.context - stable/kilo, stable/liberty
oslo.db - stable/kilo, stable/liberty
oslo.i18n - stable/kilo, stable/liberty
oslo.log - stable/kilo, stable/liberty
oslo.messaging - stable/kilo
oslo.middleware - stable/kilo, stable/liberty
oslo.policy - stable/kilo, stable/liberty
oslo.reports - stable/liberty
oslo.rootwrap - stable/kilo, stable/liberty
oslo.serialization - stable/kilo, stable/liberty
oslo.service - stable/liberty
oslo.utils - stable/kilo, stable/liberty
oslo.versionedobjects - stable/kilo
oslo.vmware - stable/kilo, stable/liberty
oslosphinx - stable/kilo, stable/liberty
oslotest - stable/kilo, stable/liberty
pycadf - stable/kilo, stable/liberty
python-barbicanclient - stable/kilo, stable/liberty
python-ceilometerclient - stable/kilo, stable/liberty
python-cinderclient - stable/kilo, stable/liberty
python-congressclient - stable/kilo, stable/liberty
python-designateclient - stable/kilo, stable/liberty
python-glanceclient - stable/kilo, stable/liberty
python-group-based-policy-client - stable/kilo
python-heatclient - stable/kilo, stable/liberty
python-ironicclient - stable/kilo, stable/liberty
python-keystoneclient - stable/kilo, stable/liberty
python-magnumclient - stable/kilo, stable/liberty
python-neutronclient - stable/kilo, stable/liberty
python-novaclient - stable/kilo, stable/liberty
python-openstackclient - stable/kilo, stable/liberty
python-saharaclient - stable/kilo, stable/liberty
python-swiftclient - stable/kilo, stable/liberty
python-tackerclient - stable/kilo, stable/liberty
python-troveclient - stable/kilo, stable/liberty
python-zaqarclient - stable/kilo, stable/liberty
requirements - stable/kilo, stable/liberty
stevedore - stable/liberty
swift - stable/kilo
tacker - stable/kilo, stable/liberty
tacker-horizon - stable/kilo, stable/liberty
taskflow - stable/kilo
tooz - stable/kilo
tripleo-common - stable/liberty
yaql - stable/kilo, stable/liberty
zaqar - stable/kilo, stable/liberty

On Wed, Dec 16, 2015 at 1:52 PM, Andreas Jaeger aj@suse.com wrote:

On 2015-12-16 12:33, Andrey Kurilin wrote:

Hi all,
As you may know, support of Python 2.6 was dropped this month from most
of OpenStack projects. Also infrastructure team dropped Centos 6.x jobs.

I'm ok with dropping Python 2.6 support from the master(Mitaka), but
what about stable/kilo and stable/liberty ? Kilo and Liberty were
released with Python 2.6 support and most of projects have py26
classifiers there. Without py26 jobs in stable branches, it is hard to
backport any changes.

Kilo and liberty was not released and neither tested on our server
projects for Python 2.6. If it had py26 classifiers, that was an error.

It was tested only on the client projects so that new python client
libraries could connect to an older installation.

Andreas

Also, requirements for stable/liberty do not contain upper caps for

python-clients and oslo. libraries, so most of projects already have
broken py26 support in Liberty.

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, 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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Andrey Kurilin.


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 16, 2015 by Andrey_Kurilin (3,820 points)   2 4
0 votes

On 12/16/2015 02:22 PM, Andrey Kurilin wrote:

If it had py26 classifiers, that was an error.

The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizon - stable/kilo, stable/liberty
astara-neutron - stable/kilo, stable/liberty
bifrost - stable/liberty
ceilometermiddleware - stable/kilo, stable/liberty
cloudkitty-dashboard - stable/kilo
compute-hyperv - stable/kilo, stable/liberty
congress - stable/kilo, stable/liberty
debtcollector - stable/kilo, stable/liberty
designate - stable/kilo, stable/liberty
designate-dashboard - stable/liberty
glance_store - stable/kilo
group-based-policy - stable/kilo
group-based-policy-automation - stable/kilo
group-based-policy-ui - stable/kilo
instack-undercloud - stable/liberty
keystoneauth - stable/liberty
keystonemiddleware - stable/kilo
magnum - stable/kilo, stable/liberty
magnum-ui - stable/liberty
manila-ui - stable/kilo, stable/liberty
mox3 - stable/liberty
networking-bagpipe - stable/kilo, stable/liberty
networking-bgpvpn - stable/kilo, stable/liberty
networking-hyperv - stable/kilo, stable/liberty
networking-infoblox - stable/liberty
networking-l2gw - stable/kilo, stable/liberty
networking-nec - stable/kilo
networking-ovs-dpdk - stable/kilo, stable/liberty
networking-plumgrid - stable/kilo, stable/liberty
networking-vsphere - stable/kilo, stable/liberty
nova-docker - stable/kilo, stable/liberty
nova-solver-scheduler - stable/kilo
os-brick - stable/liberty
os-client-config - stable/liberty
oslo-incubator - stable/kilo
oslo.cache - stable/liberty
oslo.concurrency - stable/kilo, stable/liberty
oslo.config - stable/kilo, stable/liberty
oslo.context - stable/kilo, stable/liberty
oslo.db - stable/kilo, stable/liberty
oslo.i18n - stable/kilo, stable/liberty
oslo.log - stable/kilo, stable/liberty
oslo.messaging - stable/kilo
oslo.middleware - stable/kilo, stable/liberty
oslo.policy - stable/kilo, stable/liberty
oslo.reports - stable/liberty
oslo.rootwrap - stable/kilo, stable/liberty
oslo.serialization - stable/kilo, stable/liberty
oslo.service - stable/liberty
oslo.utils - stable/kilo, stable/liberty
oslo.versionedobjects - stable/kilo
oslo.vmware - stable/kilo, stable/liberty
oslosphinx - stable/kilo, stable/liberty
oslotest - stable/kilo, stable/liberty
pycadf - stable/kilo, stable/liberty
python-barbicanclient - stable/kilo, stable/liberty
python-ceilometerclient - stable/kilo, stable/liberty
python-cinderclient - stable/kilo, stable/liberty
python-congressclient - stable/kilo, stable/liberty
python-designateclient - stable/kilo, stable/liberty
python-glanceclient - stable/kilo, stable/liberty
python-group-based-policy-client - stable/kilo
python-heatclient - stable/kilo, stable/liberty
python-ironicclient - stable/kilo, stable/liberty
python-keystoneclient - stable/kilo, stable/liberty
python-magnumclient - stable/kilo, stable/liberty
python-neutronclient - stable/kilo, stable/liberty
python-novaclient - stable/kilo, stable/liberty
python-openstackclient - stable/kilo, stable/liberty
python-saharaclient - stable/kilo, stable/liberty
python-swiftclient - stable/kilo, stable/liberty
python-tackerclient - stable/kilo, stable/liberty
python-troveclient - stable/kilo, stable/liberty
python-zaqarclient - stable/kilo, stable/liberty
requirements - stable/kilo, stable/liberty
stevedore - stable/liberty
swift - stable/kilo
tacker - stable/kilo, stable/liberty
tacker-horizon - stable/kilo, stable/liberty
taskflow - stable/kilo
tooz - stable/kilo
tripleo-common - stable/liberty
yaql - stable/kilo, stable/liberty
zaqar - stable/kilo, stable/liberty

Andrey,

I don't think it is reasonable to use these classifiers to say we are
declaring support Py2.6. Those classifier, despite their high numbers,
are just wrong. It is very annoying that you've found out how widely
spread the false declaration is. Maybe it is time that we collectively
take a better care of it.

It has been discussed in this list for a long time that we wouldn't
support Python 2.6 after Juno. Right now, it is unfortunately a way too
late to go back on this decision. There's anyway nobody that is
volunteering to do the work on the infra side.

I am well aware that this is causing problems for MOS and Fuel, with our
master node still running on CentOS 6 for Fuel/MOS 6 and 7. IMO, we
should have switch to CentOS 7 a year ago, not now, but it is too late
to regret. The only thing we can do here, is doing patches as we see
issues rising. I don't believe this kind of patch would be strongly
refused if they pass the Python 2.7 gates. If they are, then I will
strongly oppose to the refusal of such patch. Worst case, we can
maintain our own private Python 2.6 patches for the remaining time when
we need Python 2.6 in Kilo and Liberty. Let's learn from this mistake,
and have Fuel / MOS sync faster with the rest of OpenStack, so that we
don't have this kind of issue again in the future.

Feel free to propose patches to remove these Py2.6 classifiers. Maybe
the best approach for it would be having the proposal bot to do such
patches.

Cheers,

Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 16, 2015 by Thomas_Goirand (18,640 points)   3 11 16
0 votes

On 12/16/2015 8:28 AM, Thomas Goirand wrote:
On 12/16/2015 02:22 PM, Andrey Kurilin wrote:

If it had py26 classifiers, that was an error.

The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizon - stable/kilo, stable/liberty
astara-neutron - stable/kilo, stable/liberty
bifrost - stable/liberty
ceilometermiddleware - stable/kilo, stable/liberty
cloudkitty-dashboard - stable/kilo
compute-hyperv - stable/kilo, stable/liberty
congress - stable/kilo, stable/liberty
debtcollector - stable/kilo, stable/liberty
designate - stable/kilo, stable/liberty
designate-dashboard - stable/liberty
glance_store - stable/kilo
group-based-policy - stable/kilo
group-based-policy-automation - stable/kilo
group-based-policy-ui - stable/kilo
instack-undercloud - stable/liberty
keystoneauth - stable/liberty
keystonemiddleware - stable/kilo
magnum - stable/kilo, stable/liberty
magnum-ui - stable/liberty
manila-ui - stable/kilo, stable/liberty
mox3 - stable/liberty
networking-bagpipe - stable/kilo, stable/liberty
networking-bgpvpn - stable/kilo, stable/liberty
networking-hyperv - stable/kilo, stable/liberty
networking-infoblox - stable/liberty
networking-l2gw - stable/kilo, stable/liberty
networking-nec - stable/kilo
networking-ovs-dpdk - stable/kilo, stable/liberty
networking-plumgrid - stable/kilo, stable/liberty
networking-vsphere - stable/kilo, stable/liberty
nova-docker - stable/kilo, stable/liberty
nova-solver-scheduler - stable/kilo
os-brick - stable/liberty
os-client-config - stable/liberty
oslo-incubator - stable/kilo
oslo.cache - stable/liberty
oslo.concurrency - stable/kilo, stable/liberty
oslo.config - stable/kilo, stable/liberty
oslo.context - stable/kilo, stable/liberty
oslo.db - stable/kilo, stable/liberty
oslo.i18n - stable/kilo, stable/liberty
oslo.log - stable/kilo, stable/liberty
oslo.messaging - stable/kilo
oslo.middleware - stable/kilo, stable/liberty
oslo.policy - stable/kilo, stable/liberty
oslo.reports - stable/liberty
oslo.rootwrap - stable/kilo, stable/liberty
oslo.serialization - stable/kilo, stable/liberty
oslo.service - stable/liberty
oslo.utils - stable/kilo, stable/liberty
oslo.versionedobjects - stable/kilo
oslo.vmware - stable/kilo, stable/liberty
oslosphinx - stable/kilo, stable/liberty
oslotest - stable/kilo, stable/liberty
pycadf - stable/kilo, stable/liberty
python-barbicanclient - stable/kilo, stable/liberty
python-ceilometerclient - stable/kilo, stable/liberty
python-cinderclient - stable/kilo, stable/liberty
python-congressclient - stable/kilo, stable/liberty
python-designateclient - stable/kilo, stable/liberty
python-glanceclient - stable/kilo, stable/liberty
python-group-based-policy-client - stable/kilo
python-heatclient - stable/kilo, stable/liberty
python-ironicclient - stable/kilo, stable/liberty
python-keystoneclient - stable/kilo, stable/liberty
python-magnumclient - stable/kilo, stable/liberty
python-neutronclient - stable/kilo, stable/liberty
python-novaclient - stable/kilo, stable/liberty
python-openstackclient - stable/kilo, stable/liberty
python-saharaclient - stable/kilo, stable/liberty
python-swiftclient - stable/kilo, stable/liberty
python-tackerclient - stable/kilo, stable/liberty
python-troveclient - stable/kilo, stable/liberty
python-zaqarclient - stable/kilo, stable/liberty
requirements - stable/kilo, stable/liberty
stevedore - stable/liberty
swift - stable/kilo
tacker - stable/kilo, stable/liberty
tacker-horizon - stable/kilo, stable/liberty
taskflow - stable/kilo
tooz - stable/kilo
tripleo-common - stable/liberty
yaql - stable/kilo, stable/liberty
zaqar - stable/kilo, stable/liberty

Andrey,

I don't think it is reasonable to use these classifiers to say we are
declaring support Py2.6. Those classifier, despite their high numbers,
are just wrong. It is very annoying that you've found out how widely
spread the false declaration is. Maybe it is time that we collectively
take a better care of it.

It has been discussed in this list for a long time that we wouldn't
support Python 2.6 after Juno. Right now, it is unfortunately a way too
late to go back on this decision. There's anyway nobody that is
volunteering to do the work on the infra side.

I am well aware that this is causing problems for MOS and Fuel, with our
master node still running on CentOS 6 for Fuel/MOS 6 and 7. IMO, we
should have switch to CentOS 7 a year ago, not now, but it is too late
to regret. The only thing we can do here, is doing patches as we see
issues rising. I don't believe this kind of patch would be strongly
refused if they pass the Python 2.7 gates. If they are, then I will
strongly oppose to the refusal of such patch. Worst case, we can
maintain our own private Python 2.6 patches for the remaining time when
we need Python 2.6 in Kilo and Liberty. Let's learn from this mistake,
and have Fuel / MOS sync faster with the rest of OpenStack, so that we
don't have this kind of issue again in the future.

Feel free to propose patches to remove these Py2.6 classifiers. Maybe
the best approach for it would be having the proposal bot to do such
patches.

Cheers,

Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Yeah, support for python 2.6 was declared end of life as of Kilo long
ago and several times in the mailing list, this shouldn't come as a
surprise.

Many of the clients/libraries in stable/kilo and liberty still work on
py26, since their unit test jobs were passing as of a couple of weeks
ago. For that reason I don't see much of a point in globally removing
the trove classifiers on stable, but there should be an understanding
that we don't support py26 and don't test changes against py26.

But I don't really want to see is go back and actively remove py26
compat code on all active stable branches for all clients/libraries at
this point. I'm inclined to just let the py26 compat in those projects
bitrot on stable until eol.

--

Thanks,

Matt Riedemann


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 16, 2015 by Matt_Riedemann (48,320 points)   3 10 26
0 votes

Excerpts from Thomas Goirand's message of 2015-12-16 15:28:39 +0100:

On 12/16/2015 02:22 PM, Andrey Kurilin wrote:

If it had py26 classifiers, that was an error.

The list of libraries with py26 classifiers is too huge:
astara - stable/kilo, stable/liberty
astara-appliance - stable/kilo, stable/liberty
astara-horizon - stable/kilo, stable/liberty
astara-neutron - stable/kilo, stable/liberty
bifrost - stable/liberty
ceilometermiddleware - stable/kilo, stable/liberty
cloudkitty-dashboard - stable/kilo
compute-hyperv - stable/kilo, stable/liberty
congress - stable/kilo, stable/liberty
debtcollector - stable/kilo, stable/liberty
designate - stable/kilo, stable/liberty
designate-dashboard - stable/liberty
glance_store - stable/kilo
group-based-policy - stable/kilo
group-based-policy-automation - stable/kilo
group-based-policy-ui - stable/kilo
instack-undercloud - stable/liberty
keystoneauth - stable/liberty
keystonemiddleware - stable/kilo
magnum - stable/kilo, stable/liberty
magnum-ui - stable/liberty
manila-ui - stable/kilo, stable/liberty
mox3 - stable/liberty
networking-bagpipe - stable/kilo, stable/liberty
networking-bgpvpn - stable/kilo, stable/liberty
networking-hyperv - stable/kilo, stable/liberty
networking-infoblox - stable/liberty
networking-l2gw - stable/kilo, stable/liberty
networking-nec - stable/kilo
networking-ovs-dpdk - stable/kilo, stable/liberty
networking-plumgrid - stable/kilo, stable/liberty
networking-vsphere - stable/kilo, stable/liberty
nova-docker - stable/kilo, stable/liberty
nova-solver-scheduler - stable/kilo
os-brick - stable/liberty
os-client-config - stable/liberty
oslo-incubator - stable/kilo
oslo.cache - stable/liberty
oslo.concurrency - stable/kilo, stable/liberty
oslo.config - stable/kilo, stable/liberty
oslo.context - stable/kilo, stable/liberty
oslo.db - stable/kilo, stable/liberty
oslo.i18n - stable/kilo, stable/liberty
oslo.log - stable/kilo, stable/liberty
oslo.messaging - stable/kilo
oslo.middleware - stable/kilo, stable/liberty
oslo.policy - stable/kilo, stable/liberty
oslo.reports - stable/liberty
oslo.rootwrap - stable/kilo, stable/liberty
oslo.serialization - stable/kilo, stable/liberty
oslo.service - stable/liberty
oslo.utils - stable/kilo, stable/liberty
oslo.versionedobjects - stable/kilo
oslo.vmware - stable/kilo, stable/liberty
oslosphinx - stable/kilo, stable/liberty
oslotest - stable/kilo, stable/liberty
pycadf - stable/kilo, stable/liberty
python-barbicanclient - stable/kilo, stable/liberty
python-ceilometerclient - stable/kilo, stable/liberty
python-cinderclient - stable/kilo, stable/liberty
python-congressclient - stable/kilo, stable/liberty
python-designateclient - stable/kilo, stable/liberty
python-glanceclient - stable/kilo, stable/liberty
python-group-based-policy-client - stable/kilo
python-heatclient - stable/kilo, stable/liberty
python-ironicclient - stable/kilo, stable/liberty
python-keystoneclient - stable/kilo, stable/liberty
python-magnumclient - stable/kilo, stable/liberty
python-neutronclient - stable/kilo, stable/liberty
python-novaclient - stable/kilo, stable/liberty
python-openstackclient - stable/kilo, stable/liberty
python-saharaclient - stable/kilo, stable/liberty
python-swiftclient - stable/kilo, stable/liberty
python-tackerclient - stable/kilo, stable/liberty
python-troveclient - stable/kilo, stable/liberty
python-zaqarclient - stable/kilo, stable/liberty
requirements - stable/kilo, stable/liberty
stevedore - stable/liberty
swift - stable/kilo
tacker - stable/kilo, stable/liberty
tacker-horizon - stable/kilo, stable/liberty
taskflow - stable/kilo
tooz - stable/kilo
tripleo-common - stable/liberty
yaql - stable/kilo, stable/liberty
zaqar - stable/kilo, stable/liberty

Andrey,

I don't think it is reasonable to use these classifiers to say we are
declaring support Py2.6. Those classifier, despite their high numbers,
are just wrong. It is very annoying that you've found out how widely
spread the false declaration is. Maybe it is time that we collectively
take a better care of it.

It has been discussed in this list for a long time that we wouldn't
support Python 2.6 after Juno. Right now, it is unfortunately a way too
late to go back on this decision. There's anyway nobody that is
volunteering to do the work on the infra side.

I am well aware that this is causing problems for MOS and Fuel, with our
master node still running on CentOS 6 for Fuel/MOS 6 and 7. IMO, we
should have switch to CentOS 7 a year ago, not now, but it is too late
to regret. The only thing we can do here, is doing patches as we see
issues rising. I don't believe this kind of patch would be strongly
refused if they pass the Python 2.7 gates. If they are, then I will
strongly oppose to the refusal of such patch. Worst case, we can
maintain our own private Python 2.6 patches for the remaining time when
we need Python 2.6 in Kilo and Liberty. Let's learn from this mistake,
and have Fuel / MOS sync faster with the rest of OpenStack, so that we
don't have this kind of issue again in the future.

Feel free to propose patches to remove these Py2.6 classifiers. Maybe
the best approach for it would be having the proposal bot to do such
patches.

See https://review.openstack.org/#/q/topic:remove-py26-classifier

Doug

Cheers,

Thomas Goirand (zigo)


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Dec 23, 2015 by Doug_Hellmann (87,520 points)   4 5 13
...