Open Stack

Ryan,

Thanks for taking a look at these  - really appreciate it. I will work on the rebasing this week and get everything current. At the same time I can get rid of some excess code as I went through a few iterations to get to this point. There are still a lot of unaddressed edge conditions and details that need to be thought through and addressed – but once we reach consensus on the approach we can start to address them.

Thinking though the various repos in reverse order.

OVS
===

I would like to change the code to follow the model that Russell Bryant did in his patches see:  https://github.com/russellb/ovs/commits/chaining

They have several advantages:

  1.  Creates a new table for chaining which should help isolate the code and make chaining more “atomic”
  2.  He follows the port-pair/port-chain model of SFC so integration should be cleaner
  3.  Following the port-pair/port-chain model makes extending the solution to handle a chain of VNFs fairly easy.

If everyone is good with this I can work this into the patches and rebase.

Networking-OVN
===============

There is some old code here in plugin.py that I think comes out. When I added OVN as a SFC Driver there was a lot of code that I added to  networking-ovn that became obsolete. The IDL code would be modified to follow the port-pair/port-chain. model.  The biggest question I have from your comments is the interface between the networking-sfc and networking-ovn. I think I agree with you that networking-ovn should expose an interface that is called by networking-sfc and that would remove the need to subclass OVNPlugin in the networking-sfc OVN driver. Is that what you were intending?

Networking-SFC
==============

If we follow Russell’s model in OVN/OVS then there very close alignment with the SFC model and the code will become simpler. Also removing the OVNPlugin dependency will also clean things up.


Regards

John



From: Ryan Moats <rmoats at us.ibm.com<mailto:rmoats at us.ibm.com>>
Date: Sunday, May 8, 2016 at 11:23 AM
To: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
Cc: "discuss at openvswtich.org<mailto:discuss at openvswtich.org>" <discuss at openvswtich.org<mailto:discuss at openvswtich.org>>, "openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


First, apologies for the cross-posting, but when this topic came up last week,
I wasn't able to keep track of all the folks that asked to be included in the email,
so I'm doing a mass post to try and catch everybody that might be interested.

Second, John, thank you for stepping forward and mentioning that you've been
working on code for SFC and OVN!!  I took a look at your repos on github.com
(because I'm a firm believe in NOT re-inventing the wheel) and my initial
comments follow...

Networking-SFC (https://github.com/doonhammer/networking-sfc<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_networking-2Dsfc&d=CwMFAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=U1Z58onycTVLkKu5lK1k6MTi8Vx_TRm7AYdfOfjzHKU&s=f0FHv3SjQ4uiHA5szlYScnjrn-3hXOmeL5rvvYeChGY&e=>)
=============================================================

This repo is the cleanest, as I was able to merge the current networking-sfc
master on top of it with no conflicts.  Looking around, I'm not entirely
comfortable with the idea of networking-sfc making direct calls to the OVN IDL
in parallel to networking-ovn.  I believe a cleaner solution would be to
add the code to configure OVN for SFC to networking-ovn itself, and expose an
API that the driver code in networking-sfc would call.

Networking-OVN (https://github.com/doonhammer/networking-ovn<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_networking-2Dovn&d=CwMFAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=U1Z58onycTVLkKu5lK1k6MTi8Vx_TRm7AYdfOfjzHKU&s=W1GnEuKxO_aoyjJ5aMHM8vA8no-OrpSdP0hSk0AXYe4&e=>)
=============================================================

This repo makes me a bit nervous, as it claims to be 36 commits ahead
(and 129 commits behind) openstack-master.  That's a substantial drift, and
the first thing I wanted to do was see what merge conflicts might exist when
I try to merge the current master into it.  There are two merge conflicts
detected in networking_ovn/plugin.py, and given (as I understand it) the
direction of splitting the networking-ovn monolithic plugin back into ML2
and L3 service portions, I encourage you to rebase this commit (if you don't
have time, let me know and I'll see about fixing the merge issue).

OVS (https://github.com/doonhammer/ovs<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_ovs&d=CwMFAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=U1Z58onycTVLkKu5lK1k6MTi8Vx_TRm7AYdfOfjzHKU&s=H-trbUXmgMIli4e4mi8uGbkTX_BTsXjwn4-qArQiIiU&e=>)
=======================================

This repo also has some drift (in that it is 21 comits ahead and 406 commits
behind openvswitch master).  The merge conflicts I've found here are in
ovn/ovn-nb.ovsschema and ovn/northd/ovn-northd.c.  The ovsschema conflict
looks like it can be resolved by bumping the micro version of the current master
and recalculating/inserting the schema checksum.  On the other hand, the
conflicts in ovn-northd.c are a bit more numerous (I count 22 of them as I write
this).  I'm not sure what the easiest way is to get this rebased onto the
current tip of tree master...

The reason I'm interested in the rebasing exercises is I want to get to a set
of patches that can be publically committed, at which point I (wearing my
operator hat) can evaluate them to see if they meet our needs for SFC.  If you
need help with the rebasing, I'm happy to work with you...

Ryan Moats (regXboi on IRC, jayhawk87 on github)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160509/1d1e7d08/attachment.html>