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
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
