Open Stack

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