Open Stack

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:anteaya at anteaya.info] 
Sent: Monday, July 27, 2015 2:20 PM
To: openstack-dev at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev