Open Stack

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 at 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