Open Stack

Very nice thread. Sharing is caring, so... (please notice some of my 
ideas are aligned with Ihar):

* Kill bugs
* Kill bugs
* Kill bugs

* RPC Neutron Objects Callback:
     - upgrade path: That wasn't needed before, but we're going to need it.
     - implement an strategy to avoid the out-of-order issues in RPC 
messages to agents,
       if we can make it work for this API, and do it all with 
NeutronObjects (versioned objects),
       we could slim down the RPC in a lot of places.

* Keep working on the QoS challenges
    - help people with modeling new rules (DSCP first, probably),
    - ingress & egress path for bw control (already looking at this).
    - Working on bandwidth guarantees (best effort, and strict).
    - Nova integration (no overcommits/scheduling.)

* Helping on the OVS/CT firewall driver effort to cut out the complexity 
and enhance the performance
    of the security groups for the reference solution.

* Help with implementing traffic classifiers common API, and translators 
to iptables and openflow rules
    for linux agents consumption.


Russell Bryant wrote:
> 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
>