Open Stack

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