[Openstack-operators] [craton] Versions of Python to support for Craton
sorrison at gmail.com
Tue May 24 22:36:11 UTC 2016
I’m in favour of using 3.5. We are in the process of moving things to ubuntu xenial and 3.5 is native there.
BTW when is Craton planning on getting into openstack gerrit etc?
> On 25 May 2016, at 6:20 AM, Jim Baker <jim.baker at python.org> wrote:
> tl;dr - any reason why Craton should support Python 2.7 for your use case?
> First, some background: Craton is a fleet management tool under active development for standing up and maintaining OpenStack clouds. It does so by supporting inventory and audit/remediation workflows, both at scale and being pluggable. This architecture follows the model used by Rackspace public cloud; you can think of Craton as being the "2.0" version of what we use at Rackspace. Currently most of the developers are part of OSIC (so Rackspace, Intel). Craton is built on top of a variety of Oslo libraries (notably TaskFlow), but otherwise has no dependence on OpenStack components. Craton itself in turn relies on other tooling like OpenStack Ansible to actually do its work - we have no agents. More details here: https://etherpad.openstack.org/p/Fleet_Management <https://etherpad.openstack.org/p/Fleet_Management>
> We plan to make Craton a big tent OpenStack project.
> Since we are so brand new, we are trying to make the most of being greenfield. Ubuntu policy is to target new Python development only against Python 3. Other distros are similarly favoring Python 3; see https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions <https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions>
> Currently we run tox tests against both Python 2.7 and Python 3 (specifically 3.4, 3.5). For interested operators, is there a good reason why we should continue supporting 2.7?
> Such change will let us:
> Reduce development effort, because we will have not to use awkward constructs for dual support of Python 2.7 and Python 3.
> Enable use of new functionality without backports (examples: chainmap, futurist, ipaddress, etc).
> Take advantage of new functionality that has no backport support at all. Python 2.7 at this point only gets security updates.
> We may also want to further simplify by requiring a minimum of Python 3.5. Doing so would enable us to take advantage of static type hinting, for higher quality code. Feedback on that is also appreciated.
> - Jim
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators