Open Stack

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)