Hi Kuryrs, 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.
We used some slides to guide the meeting points[1]. The key takeaways for me, in no particular order, were: # General * The need for a multitenancy spec * 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. * Ilya Chukhnakov proposed an active-active HA configuration that I look forward to see a blueprint/spec for :-) # CNI * Moving Neutron port creation to the CNI driver. This will allow us to react faster to high Pod churn Kubernetes usage scenarios. * Proposal to simplify the configuration for the worker nodes by making configuration be stored preferably on K8s. If that is not possible, direct etcd. * 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. # Container-in-VM * 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). * 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. * It was discussed to make Container-in-VM configurable to support different deployment scenarios. * Ivan Coughlan to send Address pairs proposal for one of those scenarios. # Service support * The need to add LBaaSv2 support now that Neutron dropped the long deprecated LBaasv1. * 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. # Python2/Python3 * The Python3 asyncio PoC will continue its upstreaming process. * Ilya Chukhnakov will make an eventlet Py2/Py3 PoC that offers the same in the next two weeks. I will be reviewing. * 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. 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. Regards, Toni [1] https://docs.google.com/presentation/d/1A9MG2EvZBtf2sJFcuBzuv0GxYpCyfAyYzNkkEgJuPVA/edit?usp=sharing
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
