These are the stories from our team members who attended the summit and some of their key take aways from their week in Shanghai.
During the PTG I personally focused most on the Neutron (networking) community. It’s one of the largest project communities within the OpenStack project.Magnus Bergman, Senior Infrastructure Engineer
Our team recently got back from the Open Infrastructure Summit in Shanghai. This was the first ever Summit in mainland China and for good reason. Chinese companies are pouring more and more resources into basically all of the OpenStack projects, so hosting a Summit there came quite natural.
As usual the summit consisted of keynotes, presentations, hands-on labs, and the Forum. The setup of the event was a little bit different than usual with 3 days of Summit and 3 days of Project Teams Gathering (PTG) with one day overlapping.
Magnus Bergman, Senior Infrastructure Engineer
During the PTG I personally focused most on the Neutron (networking) community. It’s one of the largest project communities within the OpenStack project. In general the PTG is more of a discussion forum and topics vary. From administrative discussions as a retrospect of the latest (Train) project cycle, project participation and adjustments in online meeting frequency to more technical discussions about the future of the project.
Among the most interesting topics during this meeting, at least to me, were two topics that somewhat intertwine. The first was a suggestion to remove the ML2/linuxbridge plugin and add ML2/OVN to the main project. The second was to make it the reference implementation instead of ML2/OVS.
ML2/OVN is a more efficient and simple way to communicate with OpenVSwitch oo implement the network infrastructure the user wants to provision. It also gets rid of a number of separate neutron agents that are needed both in the ML2/linuxbridge and the ML2/OVS scenarios.
ML2/OVN and ML2/OVS
All in all, this increases the performance both for the control plane as well as the data plane. A lot of the discussions were focused on the requirements to bring ML2/OVN to feature parity with ML2/OVS. Most of it is there, but there are still some gaps that will be filled during the next cycle.
Another interesting topic was the process of migrating an existing OpenStack setup from ML2/OVS to ML2/OVN with as little impact as possible. Some groundwork has already been done and there are proof of concept scripts to do such a migration with very little downtime. Focus will be put into making those more production ready during the next cycle.
As ML2/OVN is being added to the main neutron tree, the discussion has also been initiated to remove the ML2/linuxbridge driver. The rationale for this move is to decrease the number of drivers that needs to be maintained. In addition, the feature parity gap between OVN/OVS and linuxbridge has been growing, with new features mostly being implemented in OVN/OVS. The future removal of the driver did meet some resistance from the community. Some large operators still use the linuxbridge driver and discussions will continue with some of those operators as well as on the mailing lists to come to a conclusion. One idea is to set the status of the driver to “deprecated” but keep it for a number of cycles, giving ample time to transition away from it.
Evaluation of activity levels
A full evaluation of the activity levels was made for all the stadium projects. For instance neutron-fwaas, neutron-vpnaas, and neutron-interconnect. Some of the projects have shown less activity and lack contributors to maintain them. One such project will be killed off, namely neutron-interconnect. Contributor activity has been critically low lately and no working code has been committed. It might be resurrected if somebody steps up to the challenge.
Cross team collaboration
Cross team collaboration sessions were held with the Edge SIG, the Nova project, the Kuryr team, and the Cyborg team. This is a place to discuss issues that have multiple share holders. It can include discussing requirements from other projects on the Neutron feature as well the other way around.
During the last cycle a lot of work has been put into laying the ground work for improved performance. Mainly by adding better profiling support to be able to identify potential bottle necks. In particular a slew of improvements have been added to the L3 Agent and this work will continue during the next cycle.