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

2016-07-06 Thread Ken Gaillot
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

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org


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

2016-07-05 Thread Digimer
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.

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?

___
Users mailing list: Users@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/users

Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://bugs.clusterlabs.org