[openstack-dev] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

Anita Kuno anteaya at anteaya.info
Thu Jul 30 05:42:37 UTC 2015


On 07/29/2015 02:37 PM, Armando M. wrote:
> Hi,
> 
> Since I was quoted, I would like to take the blame on behalf on the Neutron
> core reviewer/drivers team for not providing the right guidance to resolve
> the apparent conflict between the two proposals.
> 
> As some reviewers mentioned, we should really strive to catch two birds
> with one stone, and ensure that, if at all possible, the same API can
> address both use cases presented. In this case, it sounds to me that the
> API proposed by the networking-sfc sub-project is more comprehensive, it
> has taken the steps to evolve independently from the Neutron core platform,
> and it has been iterated on multiple times. Surely we can spin off (the
> forwarding engine) from the spin off (the SFC API), but that would feel
> like an overkill, especially when both have very little code to show for
> (and everyone knows that code wins in OpenStack).
> 
> We should have provided Yuji Azama feedback a lot earlier in the process
> but we didn't. Again, blame me!
> 
> I think that Sean raised a flag which should be seen as an acknowledgment
> of a need to reconcile the two efforts; let's move past the blame game and
> the language barriers, and let's figure out how to address Yuji's need
> within the context of a single effort, without dismissing it. For this
> reason I am going to suggest we iterate within the networking-sfc project,
> and block change 186663 <https://review.openstack.org/#/c/186663/>. Let's
> figure out how the model/API has to evolve to accommodate the proposed used
> need.
> 
> If you disagree, please raise your concern on the patch in review itself.
> 
> Cheers,
> Armando

Hi Armando,

If my attempts to offer some feedback on communication came across as
blame than I failed in what I was trying to accomplish.

My goal was and is to try to illustrate the point that competition and
collaboration are two separate directions.

While some folks come from a competitive background, I hold the vision
of OpenStack as a collaborative experience. Some folks many need more
time than others to understand and digest the differences in behaviour
associated with the two styles of operating.

I appreciate your email, Armando. At the very least it sets a good
example for others who many be new to collaboration to follow.

As always, it is a pleasure to work with you Armax,
Anita.

> 
> On 28 July 2015 at 15:01, Sean M. Collins <sean at coreitpro.com> wrote:
> 
>> All,
>>
>> My suggestion was as follows:
>>
>>> <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
>>
>> I think there is overlap between the two APIs. Let's keep collaborating
>> on both the networking-sfc and packet forwarding APIs, to see where we
>> have commonality. I think Cathy's initial e-mail may have ruffled
>> feathers - and I'd like to smooth them out again. I think the statement
>> "we only need one API" is far too premature.
>>
>> Let's play nice with the other API proposals, yes?
>>
>>
>> --
>> Sean M. Collins
>>
>> __________________________________________________________________________
>> 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
>>
> 
> 
> 
> __________________________________________________________________________
> 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
> 




More information about the OpenStack-dev mailing list