Open Stack

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

-- 
Russell Bryant