Hi Neutrinos, For those of you who couldn't join in person, please find a few notes below to capture some of the highlights of the event.
I would like to thank everyone one who helped me put this report together, and everyone who helped make this mid-cycle a fruitful one. I would also like to thank IBM, and the individual organizers who made everything go smoothly. Feel free to reach out if something is unclear, incorrect or incomplete. Cheers, Armando ~~~~~~~ We touched on these topics (as initially proposed on https://etherpad.openstack.org/p/neutron-mitaka-midcycle) - Neutron-lib: discussed strategy for taking base DB model and context code into neutron-lib and getting rid of common-db-mixin. More to follow/baking in - Routed-networks - Develpment started as per specification https://review.openstack.org/#/c/225384/. In particular: - Client patches - Segment extension - segments / host mapping - Troubleshooting - A number of proposals have been made over time, armax intends to push back on them all and invite the team to pause and think about this as two separate problems, which are at two different level of abstractions/complexity. Neutron, like an automobile, needs a dashboard whose warning lights provide feedback to the operator; only once this is available, well understood and well documented, remedy actions and effective tools in the toolbox can be implemented/used when digging under the bonnet. We clearly have an inexistent or an inadequate dashboard so far; figuring out what this dashboard looks like should be the first step to improve operability of Neuton deployments. More to follow on pending RFE bug. - https://bugs.launchpad.net/neutron/+bug/1507499 - Some preliminary notes available at: https://etherpad.openstack.org/p/neutron-troubleshooting - Usability and stability fixes: - MTU cleanups: Implemented all MTU changes in Nova and Neutron required to fix the interface MTU setting mismatches identified by Matt and Sean. Deprecated the old network device mtu option in Nova and Neutron. Started working on a patch to address an issue when tunnels are used over IPv6 endpoints since the additional 20 byte overhead is not accounted for. - https://bugs.launchpad.net/neutron/+bug/1542108 - https://bugs.launchpad.net/neutron/+bug/1542475 - https://review.openstack.org/#/c/283798/ - https://review.openstack.org/#/c/285532/ - https://review.openstack.org/#/c/284818/ - https://review.openstack.org/#/c/283790/ - https://review.openstack.org/#/c/284814/ - L3 HA: Worked out some race conditions in L3 HA when the server is receiving lots of router creates/deletes for the same tenant and pushed two patches to fix them. - https://review.openstack.org/#/c/282876/14 - Reduce IP consumptions for router gateway ports (both DVR and non). carl_baldwin to put up model proposal, haleyb to follow up with code. - CI jobs cleanup - Assaf and armax had a chat about the -plus job and the current marching order is: - keep the API job as is; in the medium term they would like to adopt the same approach taken by the functional job to streamline the setup (e.g. setting up Keystone and Neutron only); this way they can cut back on the time to feedback as far as API tests go. - continue to use the -plus job to run scenario tests, that requires the setup of an end-to-end cloud (Nova, Glance, Keystone, Neutron, et al). - Keeping the two jobs separate should help better tolerate, identify and isolate potential intermittent failures induced by scenario tests, by keeping the api job stable and on both check and gate queues. - Continue the de-fork effort - https://review.openstack.org/#/c/280427/ - https://review.openstack.org/#/c/285116/ - Nova integration aspects - Continued the conversation on get-me-a-network, thanks to Matt Riedemann for kickstarting the nova side of the effort - Nova spec: https://review.openstack.org/#/c/283206/ - Neutron blueprint dashboard: https://blueprints.launchpad.net/neutron/+spec/get-me-a-network - Documentation: https://review.openstack.org/#/c/283133/ - Provide validation api to reduce amount of api calls to make between nova/neutron: - https://review.openstack.org/#/c/283849/ - https://review.openstack.org/#/c/284307/ - Made progress on Nova live migration with DVR patches, including removing a flaky tempest test from the gate when neutron is enabled. - Talked about cells v2 and what Neutron can do, if at all, to adopt the same architecture. mlavalle to track nova development and put notes together. - OpenStack client transition plan - Richard and armax sat down to finalize transition plan and chose deprecation/development strategies from Newton onwards - https://review.openstack.org/#/c/282555/ - https://etherpad.openstack.org/p/osc-neutron-support - https://bugs.launchpad.net/neutron/+bug/1521291 - OVN and OVS integration - How to deal with destination MAC that OVN does not recognize - discussion on current and future work for OVN features and scale - discussion on how routed network models and FIPs fit in OVN deployments - API docs and docs in general - Sam-I-Am evangelized the importance of docs and we all listened and nodded in awe - DNS integration chapter for networking Guide - Catching up on transition plan to adopt swagger - Stadium: discussed pros and cons of approaches for structuring networking projects in openstack governance; arnax to respin https://review.openstack.org/#/c/281628/ for updates. We didn't cover everything as planned, but that's the beauty of reality shows.
__________________________________________________________________________ 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