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

[Matt Riedemann]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev