<div dir="ltr"><div>Hi Kuryrs,<br><br></div>Last Thursday, we had a very productive Kuryr-Kubernetes integration meeting. I want to thank a lot to all the people that joined the meeting for how well they prepared the meeting and the good points that were raise.<br clear="all"><div><div><div><div class="gmail_signature"><br>We used some slides to guide the meeting points[1]. The key takeaways for me, in no particular order, were:<br><br></div><div class="gmail_signature"># General<br></div><div class="gmail_signature">* The need for a multitenancy spec<br></div><div class="gmail_signature">* Using device owner, device id for resource tracking. This can come in very handy for cleaning up resources, as well as when deciding which component takes care of what.<br>* Ilya Chukhnakov proposed an active-active HA configuration that I look forward to see a blueprint/spec for :-)<br></div><br><div class="gmail_signature"># CNI<br></div><div class="gmail_signature">* Moving Neutron port creation to the CNI driver. This will allow us to react faster to high Pod churn Kubernetes usage scenarios.<br></div><div class="gmail_signature">* Proposal to simplify the configuration for the worker nodes by making configuration be stored preferably on K8s. If that is not possible, direct etcd.<br></div><div class="gmail_signature">* We noted the possibility of future optimizations by having worker nodes pull pre-allocated Neutron ports. However, this is something we'll only get into considering once we have performance numbers, as it makes the deployment less flexible.<br><br></div><div class="gmail_signature"># Container-in-VM<br><div class="gmail_signature">* We should check with Magnum about the 
communication possibilities going forward for the worker nodes to be 
able to talk to Neutron directly (see first point in #CNI).<br></div><div class="gmail_signature">* Check reference implementation of Neutron trunk/sub ports at the Host side to spot possible slow downs (like Linux Bridge) that could negate part of the advantage of using kuryr.<br></div><div class="gmail_signature">* It was discussed to make Container-in-VM configurable to support different deployment scenarios.<br></div><div class="gmail_signature">* Ivan Coughlan to send Address pairs proposal for one of those scenarios.<br><br></div><div class="gmail_signature"># Service support<br></div><div class="gmail_signature">* The need to add LBaaSv2 support now that Neutron dropped the long deprecated LBaasv1.<br></div><div class="gmail_signature">* The need for studying the options for UDP load balancing with LBaaSv2 and octavia. How far is the API from supporting it, which vendors could easily support it. The new distributed OVN load balancer got mentioned.<br><br></div><div class="gmail_signature"># Python2/Python3<br></div><div class="gmail_signature">* The Python3 asyncio PoC will continue its upstreaming process.<br></div><div class="gmail_signature">* Ilya Chukhnakov will make an eventlet Py2/Py3 PoC that offers the same in the next two weeks. I will be reviewing.<br></div><div class="gmail_signature">* When we reach feature parity, we'll evaluate the implementations and there is agreement on moving to Py2/Py3 eventlet solution to lower the barrier of adoption and due to maturity of associated libraries.<br><br></div><div class="gmail_signature">That is all. If any of the present people see that I forgot something I'll be very thankful if you add to the above points.<br><br></div><div class="gmail_signature">Regards,<br><br></div><div class="gmail_signature">Toni<br></div><br>[1] <a href="https://docs.google.com/presentation/d/1A9MG2EvZBtf2sJFcuBzuv0GxYpCyfAyYzNkkEgJuPVA/edit?usp=sharing">https://docs.google.com/presentation/d/1A9MG2EvZBtf2sJFcuBzuv0GxYpCyfAyYzNkkEgJuPVA/edit?usp=sharing</a><br></div></div>
</div></div></div>