Correcting ovs address 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 <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>> Date: Sunday, May 8, 2016 at 11:23 AM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> Cc: "disc...@openvswtich.org<mailto:disc...@openvswtich.org>" <disc...@openvswtich.org<mailto:disc...@openvswtich.org>>, "openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org>" <openstack-...@lists.openstack.org<mailto:openstack-...@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)
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
