Ryan, Thanks - let me try and get the code cleaned up and rebased. One area that I could use your insight on is the interface to networking-ovn and how it should look.
Regards John From: Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>> Date: Sunday, May 8, 2016 at 8:32 PM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> Cc: "disc...@openvswitch.org<mailto:disc...@openvswitch.org>" <disc...@openvswitch.org<mailto:disc...@openvswitch.org>>, OpenStack Development Mailing List <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote on 05/08/2016 07:34:52 PM: > From: John McDowall > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: "disc...@openvswitch.org<mailto:disc...@openvswitch.org>" > <disc...@openvswitch.org<mailto:disc...@openvswitch.org>> > Date: 05/08/2016 07:35 PM > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN > > 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_russellb_ovs_&d=CwMGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=_f4gjpVAKVX0PU6jpEYOKtT1OLwmrOSgMc0fjASz5JI&s=VyzaLKG-WTtwNtnzunX-dImm0lA0rUAiYgPMrieHJO4&e=> > 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. You are anticipating where I was looking to go, so I'm on board with this idea. > 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? Yes, I was looking at how that subclass could be avoided. > 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. Yes, I was hoping that would be a side effect as well... I like all of your proposed ideas and am looking forward to seeing the next iteration. Please feel free to reach out if you need another pair of hands to help with coding... Ryan Moats
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
