In the weekly neutron meetings it hasn't been mentioned that any of these items are at risk due to developer shortage. That's why I wanted Mark McClain to reply here because he has been leading the parity effort. On Aug 6, 2014 8:56 AM, "Joe Gordon" <joe.gord...@gmail.com> wrote:
> > > > On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton <blak...@gmail.com> wrote: > >> 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. >> > > I cannot speak for which parts of nova-parity are short staffed, if any, > but from an outsiders perspective I don't think neutron will hit full > parity in Juno. And I would be very surprised to hear that more developers > working on parity won't help. For example we are already in Juno-3 and the > following work is yet to be completed (as per the neutron gap wiki): > > * Make check-tempest-dsvm-neutron-full stable enough to vote > * Grenade testing > * DVR (Neutron replacement for Nova multi-host) > * Document Open Source Options > * Real world (not in gate) performance, stability and scalability testing > (performance parity with nova-networking). > > > >> >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
