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

Armando M. armamig at gmail.com
Thu Jul 30 15:45:07 UTC 2015


On 29 July 2015 at 22:42, Anita Kuno <anteaya at anteaya.info> wrote:

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


My point was simply to encourage the people involved in both efforts to
take action after the discussion. The resolution of using one API over the
other did not translate into a patch in any of our repos to capture the
conclusion, at least not until now anyway, and without that, any
back-and-forth is moot.

That said, I think it's important that you keep us honest along our journey
:)

Thank you!


>
> >
> > 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
> >
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150730/5ef39aad/attachment.html>


More information about the OpenStack-dev mailing list