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 -----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
