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. -- 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