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

Reply via email to