On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton <gkot...@vmware.com> wrote: > Correct, this work is orthogonal to the parity work, which I understand is > coming along very nicely.
Agree Gary and Kevin. I think the topic of Nova integration has created confusion in people’s mind (at least the non-Neutron folks) with regards to what is being proposed in the Group-based Policy (GBP) feature. So to clarify - GBP is an optional extension, like many other existing Neutron extensions. It is not meant to replace the Neutron core API and/or the current Nova-Neutron interaction in Juno. > Do new features in Nova also require parity - > https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks > (for example enables the MTU to be configured instead of via a configuration > variable) > At the moment it seems like a moving target. > > From: Kevin Benton <blak...@gmail.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Wednesday, August 6, 2014 at 9:12 AM > > To: OpenStack List <openstack-dev@lists.openstack.org> > Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way > forward > > Are there any parity features you are aware of that aren't receiving > adequate developer/reviewer time? I'm not aware of any parity features that > are in a place where throwing more engineers at them is going to speed > anything up. Maybe Mark McClain (Nova parity leader) can provide some better > insight here, but that is the impression I've gotten as an active Neutron > contributor observing the ongoing parity work. > > Given that, pointing to the Nova parity work seems a bit like a red herring. > This new API is being developed orthogonally to the existing API endpoints > and I don't think it was ever the expectation that Nova would switch to this > during the Juno timeframe anyway. The new API will not be used during normal > operation and should not impact the existing API at all. > > > On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague <s...@dague.net> wrote: >> >> On 08/05/2014 07:28 PM, Joe Gordon wrote: >> > >> > >> > >> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <kuk...@noironetworks.com >> > <mailto:kuk...@noironetworks.com>> wrote: >> > >> > On 8/4/14, 4:27 PM, Mark McClain wrote: >> >> All- >> >> >> >> tl;dr >> >> >> >> * Group Based Policy API is the kind of experimentation we be >> >> should attempting. >> >> * Experiments should be able to fail fast. >> >> * The master branch does not fail fast. >> >> * StackForge is the proper home to conduct this experiment. >> > The disconnect here is that the Neutron group-based policy sub-team >> > that has been implementing this feature for Juno does not see this >> > work as an experiment to gather data, but rather as an important >> > innovative feature to put in the hands of early adopters in Juno and >> > into widespread deployment with a stable API as early as Kilo. >> > >> > >> > The group-based policy BP approved for Juno addresses the critical >> > need for a more usable, declarative, intent-based interface for >> > cloud application developers and deployers, that can co-exist with >> > Neutron's current networking-hardware-oriented API and work nicely >> > with all existing core plugins. Additionally, we believe that this >> > declarative approach is what is needed to properly integrate >> > advanced services into Neutron, and will go a long way towards >> > resolving the difficulties so far trying to integrate LBaaS, FWaaS, >> > and VPNaaS APIs into the current Neutron model. >> > >> > Like any new service API in Neutron, the initial group policy API >> > release will be subject to incompatible changes before being >> > declared "stable", and hence would be labeled "experimental" in >> > Juno. This does not mean that it is an experiment where to "fail >> > fast" is an acceptable outcome. The sub-team's goal is to stabilize >> > the group policy API as quickly as possible, making any needed >> > changes based on early user and operator experience. >> > >> > The L and M cycles that Mark suggests below to "revisit the status" >> > are a completely different time frame. By the L or M cycle, we >> > should be working on a new V3 Neutron API that pulls these APIs >> > together into a more cohesive core API. We will not be in a position >> > to do this properly without the experience of using the proposed >> > group policy extension with the V2 Neutron API in production. >> > >> > >> > If we were failing miserably, or if serious technical issues were >> > being identified with the patches, some delay might make sense. But, >> > other than Mark's -2 blocking the initial patches from merging, we >> > are on track to complete the planned work in Juno. >> > >> > -Bob >> > >> > >> > >> > As a member of nova-core, I find this whole discussion very startling. >> > Putting aside the concerns over technical details and the pain of having >> > in tree experimental APIs (such as nova v3 API), neutron still isn't the >> > de-facto networking solution from nova's perspective and it won't be >> > until neutron has feature and performance parity with nova-network. In >> > fact due to the slow maturation of neutron, nova has moved nova-network >> > from 'frozen' to open for development (with a few caveats). So unless >> > this new API directly solves some of the gaps in [0], I see no reason to >> > push this into Juno. Juno hardly seems to be the appropriate time to >> > introduce a new not-so-stable API; Juno is the time to address all the >> > gaps [0] and hit feature and performance parity with nova-network. >> > >> > >> > [0] >> > >> > https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage >> >> I would agree. >> >> There has been a pretty regular issue with Neutron team members working >> on new features instead of getting Neutron to feature parity with Nova >> network so we can retire the thing. This whole push for another API at >> this stage makes no sense to me. >> >> -Sean >> >> -- >> Sean Dague >> http://dague.net >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Kevin Benton > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
