<html><body><p><tt>First, apologies for the cross-posting, but when this topic came up last week,</tt><br><tt>I wasn't able to keep track of all the folks that asked to be included in the email,</tt><br><tt>so I'm doing a mass post to try and catch everybody that might be interested.</tt><br><br><tt>Second, John, thank you for stepping forward and mentioning that you've been</tt><br><tt>working on code for SFC and OVN!! I took a look at your repos on github.com</tt><br><tt>(because I'm a firm believe in NOT re-inventing the wheel) and my initial </tt><br><tt>comments follow...</tt><br><br><tt>Networking-SFC (</tt><a href="https://github.com/doonhammer/networking-sfc"><tt>https://github.com/doonhammer/networking-sfc</tt></a><tt>)</tt><br><tt>=============================================================</tt><br><br><tt>This repo is the cleanest, as I was able to merge the current networking-sfc</tt><br><tt>master on top of it with no conflicts. Looking around, I'm not entirely</tt><br><tt>comfortable with the idea of networking-sfc making direct calls to the OVN IDL</tt><br><tt>in parallel to networking-ovn. I believe a cleaner solution would be to </tt><br><tt>add the code to configure OVN for SFC to networking-ovn itself, and expose an</tt><br><tt>API that the driver code in networking-sfc would call. </tt><br><br><tt>Networking-OVN (</tt><a href="https://github.com/doonhammer/networking-ovn"><tt>https://github.com/doonhammer/networking-ovn</tt></a><tt>)</tt><br><tt>=============================================================</tt><br><br><tt>This repo makes me a bit nervous, as it claims to be 36 commits ahead</tt><br><tt>(and 129 commits behind) openstack-master. That's a substantial drift, and</tt><br><tt>the first thing I wanted to do was see what merge conflicts might exist when</tt><br><tt>I try to merge the current master into it. There are two merge conflicts</tt><br><tt>detected in networking_ovn/plugin.py, and given (as I understand it) the</tt><br><tt>direction of splitting the networking-ovn monolithic plugin back into ML2</tt><br><tt>and L3 service portions, I encourage you to rebase this commit (if you don't</tt><br><tt>have time, let me know and I'll see about fixing the merge issue).</tt><br><br><tt>OVS (</tt><a href="https://github.com/doonhammer/ovs"><tt>https://github.com/doonhammer/ovs</tt></a><tt>)</tt><br><tt>=======================================</tt><br><br><tt>This repo also has some drift (in that it is 21 comits ahead and 406 commits</tt><br><tt>behind openvswitch master). The merge conflicts I've found here are in</tt><br><tt>ovn/ovn-nb.ovsschema and ovn/northd/ovn-northd.c. The ovsschema conflict</tt><br><tt>looks like it can be resolved by bumping the micro version of the current master</tt><br><tt>and recalculating/inserting the schema checksum. On the other hand, the</tt><br><tt>conflicts in ovn-northd.c are a bit more numerous (I count 22 of them as I write</tt><br><tt>this). I'm not sure what the easiest way is to get this rebased onto the</tt><br><tt>current tip of tree master...</tt><br><br><tt>The reason I'm interested in the rebasing exercises is I want to get to a set</tt><br><tt>of patches that can be publically committed, at which point I (wearing my</tt><br><tt>operator hat) can evaluate them to see if they meet our needs for SFC. If you</tt><br><tt>need help with the rebasing, I'm happy to work with you...</tt><br><br><tt>Ryan Moats (regXboi on IRC, jayhawk87 on github)</tt><BR>
</body></html>