Open Stack

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

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160524/b0b59ffa/attachment.html>