+1 Kevin. I really fail to see how a patch which has been ready for a long time now is the worst enemy of Nova Parity. This is starting to feel kind of ad-hoc... On Aug 6, 2014 11:42 PM, "Kevin Benton" <[email protected]> wrote:
> >In all seriousness, folks, I'm bringing up points about the proposed API > because I see the current mess of Neutron integration with Nova, I see that > nova-network has been "undeprecated" due to continuing lack of parity and > HA concerns in Neutron, and I want things to be better, not worse. > > Again, I haven't seen any evidence that ongoing development of this new > API is preventing any of the parity work from happening. Nobody is > advocating that the parity work be delayed because of this. We are all > aware of the threats the TC has put forth with regard to demoting Neutron > to incubation unless the parity demands are met. If you want ongoing > development to stop, this should be a clear requirement and it should be > evenly applied to all work (LBaaS separation, ML2 enhancements, any third > party drivers, etc). > > > > On Wed, Aug 6, 2014 at 3:10 PM, Jay Pipes <[email protected]> wrote: > >> On 08/06/2014 04:51 PM, Pedro Marques wrote: >> >>> Neutron allows vendors to speak to proprietary device APIs, it was >>> designed to do so, AFAIK. It is also possibly to "entirely swap out >>> all of the Neutron core"... the proponents of the group based policy >>> didn't have to go through so much trouble if that was their intent. >>> As far as i know most plugins talk to a proprietary API. >>> >>> I happen to disagree technically with a couple of choices made by >>> this proposal; but the blueprint was approved. Which means that i >>> lost the argument, or didn't raise it on time, or didn't argue >>> convincingly... regardless of the reason, the time to argue about the >>> goal has passed. The decision of the community was to approve the >>> spec and that decision should be respected. >>> >> >> Sure, no problem. I'll just go back to Nova and wait around to help clean >> up the mess. >> >> In all seriousness, folks, I'm bringing up points about the proposed API >> because I see the current mess of Neutron integration with Nova, I see that >> nova-network has been "undeprecated" due to continuing lack of parity and >> HA concerns in Neutron, and I want things to be better, not worse. >> >> Neutron contributors need to recognize that Nova is the pre-eminent >> consumer of Neutron interfaces, and until those interfaces are stable, >> consistent regardless of underlying hardware or driver choices, and >> generally preferable for Nova to recommend as its default network driver, >> then the Neutron project is sitting as an island unto itself. >> >> The fact that not enough Nova developers (including yours truly) are >> paying attention to what is going on in Neutron spec-land and roadmap is a >> serious problem we should deal with directly (cross-project spec meetings, >> better documentation and communication, shared bug triaging and >> verification meetings, etc). Otherwise, these kinds of conversations are >> likely to continue. >> >> Best, >> -jay >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > -- > Kevin Benton > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
