On 07/31/2015 01:45 AM, Armando M. wrote: > On 29 July 2015 at 22:42, Anita Kuno <ante...@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!
Thanks Armando, Anita. > > >> >>> >>> 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 >>> >> >> >> __________________________________________________________________________ >> 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 > __________________________________________________________________________ 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