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
