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

Ken Gaillot kgaillot at redhat.com
Wed Jul 6 10:49:39 EDT 2016


On 07/05/2016 06:49 PM, Digimer wrote:
> On 05/07/16 01:31 PM, Ken Gaillot wrote:
>> 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.
>>
>> 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" ;-)
> 
> If this can be done without breaking RHEL 6 deployments (and it sounds
> like it wouldn't be an issue), then I say go for it. A key to good HA is
> simplicity, and maintaining two branches (or getting stuck on a dead-end
> branch) seems to go against that ethos.

It would not break stock RHEL 6 deployments, but it would introduce an
upstream break.

RHEL 6 recently entered its "Production 2" phase [1], meaning it will
get only bugfixes and not new features. So, its stock packages won't be
affected by changes we make upstream (aside from bugfixes that may be
backported).

With the proposed change, you couldn't build upstream 1.1.16 or later on
RHEL 6 and get 100% functionality (at least, not without also building
python 2.7). At this point, the only thing that would be affected would
be portions of the test suite.

[1] https://access.redhat.com/support/policy/updates/errata




More information about the Users mailing list