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 On 28 July 2015 at 15:01, Sean M. Collins <s...@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-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