On 07/27/2015 07:15 PM, Cathy Zhang wrote: > Hi Anita, > > Not sure if you read the logs. The concern on > https://review.openstack.org/#/c/186663/ and duplication were brought up by > Sean. > The goal is to have one set of API instead of multiple APIs with minor > differences. The consensus is that the SFC API seems more general than the > forwarding API, the forwarding API can be covered by the chain API, and the > forwarding API is just a chain of 1 (a special case of chain API). Here are > some snips of the meeting log related to this discussion. Per my action items > of the meeting, I am sending out an email updating everyone about our > discussion and consensus. No one can force anyone else to do anything. This > community project team have done diligence to reach out to authors of > https://review.openstack.org/#/c/186663/ multiple times before about > collaboration and convergence of APIs (Please refer to previous meeting > logs). > > ------------------------------- > 17:11:55 <pcarver> vikram: it's not the same but it has a lot in common. If > we're going to have both there will need to be extremely clear documentation > to guide operators and tenants on when to use each. > 17:12:16 <pcarver> Especially if the two can interact in unpredictable ways > 17:12:19 <vikram> pcarver: i agree.. > 17:12:23 <sc68cal> I just feel like there are some things that are in common, > the idea of redirecting traffic - the mechanics may be different but I don't > like this idea of "oh it's just a little bit different, therefore a whole new > separate API is justified" > 17:12:52 <vikram> sc68cal: hmmmm > 17:13:20 <pcarver> cathy_: I understand the desire to not have too many > dependencies, but it may make sense to have a have one be a degenerate case > of the other > 17:13:42 <pcarver> as opposed to two unrelated things that appear similar to > the user > 17:14:04 <LouisF> sc68cal: the sfc is more general than the forwarding spec > 17:14:30 <LouisF> its functionality can be covered by the sfc spec > 17:14:36 <vikram> sc68cal, pcarver: I agree, service function chaining can > achieve the use case defined in forwarding spec > 17:15:06 <pcarver> LouisF, vikram: I haven't reviewed 186663 before looking > at it just now, but is there a reason why it couldn't be implemented as a > trivially simple service chain? > > ---------------------------------- > 17:15:31 <cathy_> vikram:agree with you. Would you like to talk with Yuji on > that ? > 17:15:32 <vikram> pcarver: I believe it can > 17:15:36 <LouisF> pcarver: yes I think that can be done > 17:16:03 <sc68cal> yeah I mean I could be stupid but the forwarding API is > basically just a chain of 1 > ---------------------------------- > 17:16:11 <vikram> cathy_: We can put our concerns over the etherpad link > shared for this spec > 17:16:14 <sc68cal> and BTW - fwaas is going to be a chain of 1 > 17:16:26 <vikram> https://etherpad.openstack.org/p/forwarding-rule > 17:16:27 <sc68cal> if we're inserting a firewall between an instance and the > rest of the network > 17:16:52 <sc68cal> I had hoped to consume SFC, to look into making fwaas more > flexible > 17:17:00 <vikram> sc68cal:+++100 > 17:17:41 <pcarver> sc68cal: +1, security functions are a primary example of > the reason for SFC, although not all chained functions are firewallish > 17:17:55 <jwarendt> +1 > 17:18:27 <cathy_> So we all agree that the service chain API can cover the > functionality needed in https://review.openstack.org/#/c/186663/ > 17:18:41 <LouisF> +1 > 17:18:58 <pcarver> I'm also hearing requirements from the NFV side wanting to > replicate hub and spoke topologies. I'm viewing that also as a subset of SFC > ------------------------- > 17:21:16 <cathy_> So how should we make sure there is no duplicate API? Maybe > Vikram can communicate this with Yuji? Suggestion? > 17:22:13 <sc68cal> I'd say maybe an e-mail to the ML, with the results of > this meeting, and say that we want to try and converge where there is > commonality > 17:22:19 <vikram> cathy_: sure.. i have posted a comment on the spec.. will > try to catch him tomorrow over IRC as wekk
I'm suggesting to both yourself and Louis that a bit of humility would be a welcome consideration to your communications. Thank you, Anita. > > > > -----Original Message----- > From: Anita Kuno [mailto:ante...@anteaya.info] > Sent: Monday, July 27, 2015 2:20 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] The proposed "Neutron API extension for packet > forwarding" has a lot of duplication to the Neutron SFC API > > On 07/24/2015 06:50 PM, Cathy Zhang wrote: >> Hi Everyone, >> In our last networking-sfc project IRC meeting, an issue was brought up that >> the API proposed in https://review.openstack.org/#/c/186663/ has a lot of >> duplication to the SFC API https://review.openstack.org/#/c/192933/ that is >> being currently implemented. In the IRC meeting, the project team reached >> consensus that we only need one API and the service chain API can cover the >> functionality needed by https://review.openstack.org/#/c/186663/. Please >> refer to the meeting log >> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-07-23-17.02.log.html >> for more discussion info. Please let us know if you have different opinion. >> Thanks, >> Cathy >> >> >> >> >> __________________________________________________________________________ >> 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 >> > > I think you need to acknowledge in both email topic and in content that > Sean tried to draw the fact that you are duplicating this work on July > 16th. Collaboration is much more than "our meeting decided you shouldn't > do your work". Perhaps taking a step back and acknowledging the work of > others might set a nicer tone to your efforts. > > Thanks, > Anita. > > __________________________________________________________________________ > 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 > > __________________________________________________________________________ > 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 > __________________________________________________________________________ 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
