<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">BTW when is Craton planning on getting into openstack gerrit etc?</div><div class=""><br class=""></div><div class="">Sam</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 25 May 2016, at 6:20 AM, Jim Baker <<a href="mailto:jim.baker@python.org" class="">jim.baker@python.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">tl;dr - any reason why Craton should support Python 2.7 for your use case?</div><div class=""><br class=""></div><div class="">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 - <b class="">we have no agents</b>. More details here: <a href="https://etherpad.openstack.org/p/Fleet_Management" class="">https://etherpad.openstack.org/p/Fleet_Management</a></div><div class=""><br class=""></div><div class="">We plan to make Craton a big tent OpenStack project.<br class=""></div><div class=""><br class=""></div><div class="">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 <a href="https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions" class="">https://wiki.openstack.org/wiki/Python3#Status_of_Python_3_in_Linux_distributions</a></div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Such change will let us:</div><div class=""><ul class=""><li class="">Reduce development effort, because we will have not to use awkward constructs for dual support of Python 2.7 and Python 3.<br class=""></li><li class="">Enable use of new functionality without backports (examples: chainmap, futurist, ipaddress, etc).<br class=""></li><li class="">Take advantage of new functionality that has no backport support at all. Python 2.7 at this point only gets security updates.</li></ul><div class="">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.</div></div><div class=""><br class=""></div><div class="">- Jim</div></div>
_______________________________________________<br class="">OpenStack-operators mailing list<br class=""><a href="mailto:OpenStack-operators@lists.openstack.org" class="">OpenStack-operators@lists.openstack.org</a><br class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators<br class=""></div></blockquote></div><br class=""></div></div></body></html>