[ClusterLabs] Antw: Proposed change for 1.1.16: ending python 2.6 compatibility

[Ken Gaillot]

On 07/06/2016 01:07 AM, Ulrich Windl wrote:
>>>> Ken Gaillot <kgaillot at redhat.com> schrieb am 05.07.2016 um 19:31 in Nachricht
> <577BEEF9.4000202 at redhat.com>:
>> As you may be aware, python 3 is a significant, backward-compatible
>> restructuring of the python language. Most development of the python 2
>> series has ended, and support for python 2 will completely end in 2020.
>>
>> Pacemaker currently uses python only in its test suites. At some point,
>> we may convert a few existing Pacemaker-provided resource agents and
>> fence agents to python as well.
>>
>> Currently, Pacemaker's python code is compatible with python 2.6 and
>> 2.7. We definitely need to start moving toward python 3 compatibility.
>> It is possible to support both 2.7 and 3 with the same code, but we need
>> to lose compatibility with 2.6. (Maintaining a separate branch of code
>> for 2.6 would not be worth the effort.)
>>
>> So, I propose that Pacemaker stop supporting python 2.6 as of the next
>> version (1.1.16, expected sometime in the fall or winter). Not all our
>> python code is likely to be python3-compatible by that time, but we can
>> start moving in that direction.
> 
> I just checked three servers:
> SLES10 SP4 uses python 2.4, but no pacemaker
> SLES11 SP4 uses python 2.6
> SLES12 SP1 uses python 2.7
> 
> As SP4 is the last SP for SLES11, I guess there won't be any update for pacemaker (not to talk about python)
> In SLES12 there is a python3 available, but not installed by default.

SLES11 would be in the same boat as RHEL6 -- the stock packages would
continue to work, but upstream builds would not be 100% functional (only
a portion of the test suite would be affected, currently).

>> If anyone has any reasons to do this differently, let me know. As this
>> only affects the test suites currently, and most Linux distributions
>> have stopped supporting python 2.6 already, I expect more "what took you
>> so long" responses than "slow down" ;-)
> 
> Maybe push python 3 first ;-)

Even with the proposed change, we'd maintain compatibility with python
2.7, almost certainly until the 2020 support cutoff, or even later.

There are some convenient tools for writing python code compatible with
both 2.7 and 3, but not 2.6, which is why we have to drop 2.6
compatibility to add 3 compatibility.