On 10/02/2015 11:32 AM, Russell Bryant wrote: > On 10/01/2015 03:26 PM, Russell Bryant wrote: >> On 10/01/2015 09:45 AM, Ihar Hrachyshka wrote: >>> Hi all, >>> >>> I talked recently with several contributors about what each of us >>> plans for the next cycle, and found it’s quite useful to share >>> thoughts with others, because you have immediate yay/nay feedback, >>> and maybe find companions for next adventures, and what not. So >>> I’ve decided to ask everyone what you see the team and you >>> personally doing the next cycle, for fun or profit. >>> >>> That’s like a PTL nomination letter, but open to everyone! :) No >>> commitments, no deadlines, just list random ideas you have in mind >>> or in your todo lists, and we’ll all appreciate the huge pile of >>> awesomeness no one will ever have time to implement even if >>> scheduled for Xixao release. >>> >>> To start the fun, I will share my silly ideas in the next email. >> >> Nice thread! >> >> Here's a rough cut of what I have in mind. My Neutron related >> development time covers a few areas: Neutron, OVN itself, and the >> networking-ovn plugin for Neutron. >> >> For Neutron: >> >> - general code reviews. I'm especially interested in reviewing the >> design and implementation of any new APIs people are adding. Feel >> free to add me to reviews you think I could help with and I'll take >> a look. >> >> - plugin infrastructure. Ihar mentioned in one of his items that >> there are features implemented as ML2 specific. That has started >> to be a pain for networking-ovn. For example, the provider networks >> extension is only implemented for ML2, and the data is only stored >> in an ML2 specific db table. The db table and related code should >> be reusable by other plugins. I'd like to help start to clean that >> up for the sake of other plugins. >> >> For OVN and networking-ovn: >> >> First, for anyone not already familiar with OVN, it is an effort >> within the Open vSwitch project to build a virtual networking control >> plane for OVS. There are several projects that have implemented >> something in this space (including Neutron). OVN is intended to be a >> new, common implementation of this functionality that can be reused in >> many contexts, including by Neutron. It includes a focus on >> implementation of features taking advantage of the newest features of >> OVS, including some still being added as we go. There was a >> presentation about this in Vancouver [1] and we'll be doing another >> one covering current status in Tokyo [2]. >> >> This plugin is developed in parallel with OVN itself. My time on each >> changes week to week, depending on what I'm working on. The dev items >> I expect in the near future (this release cycle at least) include: >> >> - security groups. This is being implemented using conntrack suport >> in OVS. There's actually WIP code for this including kernel >> changes, ovs userspace changes, OVN, and networking-ovn. This is a >> complex stack of dependencies, but it's starting to fall into place. >> Most of the kernel changes have been accepted, thought there's >> another change being reviewed now. The OVS userspace changes have >> been under review in the last few weeks and are close to being >> merged. Once that's done, we can finish up testing the OVN and >> networking-ovn patches. We expect this to be done by Tokyo. >> >> - provider networks. There's a lot of demand in OpenStack for >> supporting direct connectivity to existing networks as a simpler >> deployment model without any overlays. I've done most of the work >> for both OVN and networking-ovn for this now and expect to have it >> wrapped up in the next week or so. >> >> - L3. So far we've been using Neutron's L3 agent with networking-ovn. >> OVN will have native L3 support (will no longer use the L3 agent) >> and development on that has now started. We aim to at least have >> initial distributed L3 support by Tokyo. Some of it will certainly >> extend past that, though. For example, NAT will be implemented with >> an OVS native solution, and that will likely not be ready by Tokyo. >> We may be able to deliver an intermediary NAT solution quicker. >> >> - SFC. There's a ton of interest in SFC. I've been casually following >> the networking-sfc project and the Neutron API they are proposing. >> I've also been thinking about how to implement it in OVN. I think >> OVN's logical flows abstraction is going to make it surprisingly easy >> to implement. I think I have a good idea of what needs to be done, >> but I'm not sure of when it will bubble up on my todo list. I hope >> to work on it for this dev cycle though. I'd first be implementing >> it in OVN, and then later doing the support for the networking-sfc >> API. >> >> - l2gw. OVN already includes support for VTEP gateways. We also just >> merged a patch to support them through the Neutron API using a >> networking-ovn specific binding:profile. This is just a first step, >> though. We'd like to support this with a proper Neutron abstraction. >> The networking-l2gw project is working on that abstraction so I'd >> like to help out there, expand it as necessary, and get an OVN >> backend for that API. >> >> - containers. OVN has had a focus on supporting container networking >> from the start. One way is that OVN can be used directly to build >> overlay networks independent of whatever infrastructure the container >> app is running on. This is conceptually similar to other things like >> Flannel. A major downside of overlay based container networking is >> the performance hit you get when you end up with an "overlays on >> overlays", where you can't take advantage of NIC offload support >> for overlay encapsulation. >> >> To address the performance issue, OVN includes abstractions to >> provide networking for a hybrid environment of bare metal, VMs, >> and containers. In the OpenStack case, containers running on >> bare metal or containers running inside of OpenStack VMs should >> all be able to talk to the Neutron API of the underlying OpenStack >> to provide the desired network topology. networking-ovn supports >> this already, but with a networking-ovn specific binding-profile: >> >> http://docs.openstack.org/developer/networking-ovn/containers.html >> >> I'd like to help ensure that the "VLAN aware VMs" spec gets reviewed >> and merged this cycle, as that API provides the proper Neutron >> abstraction for what's needed here. >> >> Once *that* is done, I'd really like to see some native Kubernetes >> integration to be able to talk to the Neutron API and set up the >> networking needed for container apps running in OpenStack VMs, but >> it seems unlikely that I'll get to that this cycle myself. >> >> - testing. We have a tempest job for networking-ovn that's passing. >> It skips a few tests for things we haven't finished implementing [3]. >> I'd like to get down to where we're not skipping anything. Since >> it's passing, I'd like to get to where we can run the job against >> Neutron patches, as well. I'd propose it as a non-voting job, but >> it would be running in OpenStack's infrastructure. Running against >> Neutron would get the job running much more frequently to help us >> shake out bugs and would also help us catch issues between Neutron >> and networking-ovn quicker. Finally, I'd also like to build a >> multi-node test job. >> >> - native DHCP support. Right now networking-ovn uses the existing >> Neutron DHCP agent. We plan to add native distributed DHCP support >> to OVN. Once someone gets around to it, the DHCP agent will no >> longer be used. >> >> I'm sure I've forgotten something, but this seems like a pretty good >> overview of what I expect to see this cycle. I'd love to hear any >> comments or questions you may have. >> >> We're also interested in any new contributors! Feel free to reach out >> to me for help getting started. >> >> [1] >> https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/ovn-native-virtual-networking-for-open-vswitch >> [2] >> https://openstacksummitoctober2015tokyo.sched.org/event/89a27d6b5bab975a7a4f49ec57ee5210#.Vg2DmXUVhBc >> [3] >> http://git.openstack.org/cgit/openstack/networking-ovn/tree/devstack/devstackgaterc >> > > One other reference ... if you're interested in looking more closely at > how OVN works outside of testing it with OpenStack, I wrote up a > tutorial for testing OVN in a simulated environment here: > > https://github.com/russellb/ovs/blob/localnet-vlan/tutorial/OVN-Tutorial.md > > I plan to extend it for exploring new features as they get merged. >
except that was supposed to be the link to the file in the actual ovs git repo, oops. https://github.com/openvswitch/ovs/blob/master/tutorial/OVN-Tutorial.md -- Russell Bryant __________________________________________________________________________ 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