<div><div>Hi Toni,</div><div><br></div><div><div><br></div><div>I am +1 on a). Kuryr-kubernetes is an asynchronous service. We are not talking about some binary/unicode mismatch or list/generators return type that can be solved with 'six' library or some 'utils' module.  If we go to python2 that will force us to re-do all the core part of the project when we'll move to python3.</div><div><br></div><div><div style="line-height: 19.6px;">Is there a policy that prevents to run some services on python2 and some on python3 in distros? What's the reason behind? </div></div><div><br></div><div><br></div><div>Regards,</div><div><br></div><signature>Jaume Devesa<div>Software Engineer @ Midokura</div></signature></div></div><img class="n1-open" width="0" height="0" style="border:0; width:0; height:0;" src="https://link.nylas.com/open/cxy7986hfe7y675s4rqwe1j9/local-7df6cd38-7e0a?r=b3BlbnN0YWNrLWRldkBsaXN0cy5vcGVuc3RhY2sub3Jn">
      <div class="gmail_quote">
        <br>
        On Aug 30 2016, at 4:44 pm, Antoni Segura Puimedon <celebdor@gmail.com> wrote:
        <br>
        <blockquote class="gmail_quote"
          style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
          <div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi fellow kuryrs!<br><br></div><div>This email is gonna be a bit long, so I'll put it in parts.<br><br></div><div>Kubernetes integration components<br>==========================<br></div><div><br></div>As you know, we are now in the process of upstreaming the Kuryr Kubernetes PoC that the Kuryr team at Midokura did. This PoC upstreaming effort has two main parts:<br><br>Kuryr watcher: Based on Python3 asyncio, it connects to the ?watch=true Kubernetes resource endpoints, then passes the seen events to translators that end up calling Neutron. With the Neutron resource information returned by the translators, the watching coroutines update the resource that originated the event.<br><br></div>Kuryr CNI: Py2 and Py3 compatible. It is called by Kubernetes' Kubelet with the noop container so that the CNI driver does the network plumbing for it. Basically we use openstack/kuryr binding code to bind Pod veths to Neutron ports.<br><br></div><div>Upstream Deployment design<br>======================<br></div><div><br></div>In the Kuryr-Kubernetes integration vision, Kuryr CNI is installed wherever Kubelet is and the Kuryr watcher (or watchers once we support HA) runs in a container somewhere that can access the Kubernetes, Neutron and Keystone APIs (which does not need to be able to access the watcher host on anything else that established connections). The idea behind allowing it to be in a non-privileged container somewhere is that in this way you do not need to make Neutron/Keystone accessible from the Kubernetes worker nodes, just like for a lot of Nova compute deployments (obviously, depending on you networking vendor, you have rabbitmq agent access to Neutron).<br><br>If one does not need the extra isolation for the Kuryr Watcher, the Watcher containers could even be started by Kubernetes and the CNI driver would just let the watcher container in the Host networking instead of on the Overlay, so Kubernetes would manage the integration deployment.<br><br></div><div>OpenStack distributions: when the rubber meets the road<br>==========================================<br></div><div><br></div>If the OpenStack distros, however, would prefer not to run Kuryr Watcher containerized or they want to, as they probably should, build their own container (rather than the upstream kuryr/kubernetes one in dockerhub that is based on alpine linux), they would need to have Python3.5 support. I understand that at the moment from the most popular OpenStack distros, only one has Python 3.5 supported.<br><br></div>You can imagine where this is heading... These are the options that I can see:<br><br></div>a) Work with the OpenStack distributions to ensure python3.5 support is reached soon for Kuryr and its dependencies (some listed below):<br><ul><li>babel</li><li>oslo.concurrency</li><li>oslo.config</li><li>oslo.log</li><li>oslo.utils</li><li>pbr</li><li>pyroute2</li><li>python-neutronclient</li><li>python-keystoneclient</li></ul><p>This also implies that distros should adopt a policy about having OpenStack services running in Python2, some in Python3, as I think the best is to have each project move at its own speed (within reason).<br></p><p>b) As Ilya Chukhnakov from Mirantis proposed, drop Python3 for now and reimplement it with python-requests and eventlet. He'll work on a PoC to see its feasibility and how it compares to the asyncio based one.<br></p>Personal position<br>=============<br><br></div>I see this as a good opportunity for the OpenStack community at wide to start having Python3-first (and even python3 only) services and allow OpenStack projects to take full advantage of all the good things Python3 has to offer and move forward with the rest of the Python community.<br><br></div><div>There's been some efforts in the part in some projects [1][2] but it seems implementation was deferred indefinitely probably to the same distribution issue that we face now.<br></div><div><br></div>In light of the recent discussions in this mailing list and the decision taken by the Technical Committee [3] about alternative languages. I think it would be very good for the community to set an official plan and incentivize the projects to move to Python3 in future releases (unfortunately, library projects like clients and oslo will most likely have to keep python2 for longer, but it is probably for the best).<br><br></div>While such position is not taken, I would like to hear what the rest of the Kuryr (and the rest of OpenStack) has to say about the matter and we should at least evaluate the possibility of having to do the option (b) above.<br><div><div><div><div><div><div><br></div><div>Sorry for the long wall of text, and looking forward to discuss options (a) and (b) both in these thread and in the next Kuryr weekly meeting this coming Monday,<br><br></div><div>Toni<br></div><div><br clear="all"><div><div><div>[1] <a href="https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio#What.27s_wrong_with_eventlet.3F&r=b3BlbnN0YWNrLWRldkBsaXN0cy5vcGVuc3RhY2sub3Jn">https://wiki.openstack.org/wiki/Oslo/blueprints/asyncio#What.27s_wrong_with_eventlet.3F</a><br>[2] <a href="https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor&r=b3BlbnN0YWNrLWRldkBsaXN0cy5vcGVuc3RhY2sub3Jn">https://blueprints.launchpad.net/oslo.messaging/+spec/asyncio-executor</a><br>[3] <a href="http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html&r=b3BlbnN0YWNrLWRldkBsaXN0cy5vcGVuc3RhY2sub3Jn">http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-08-02-20.01.log.html</a><br><div><div><div><div class="gmail_signature"><br></div></div>
</div></div></div></div></div></div></div></div></div></div></div></div>
        </blockquote>
      </div>