<p dir="ltr">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. </p>
<div class="gmail_quote">On Aug 6, 2014 8:56 AM, "Joe Gordon" <<a href="mailto:joe.gordon0@gmail.com">joe.gordon0@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton <span dir="ltr"><<a href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">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.</div>
</blockquote><div><br></div><div>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):</div>
<div><br></div><div>* Make check-tempest-dsvm-neutron-full stable enough to vote</div><div>* Grenade testing</div><div>* DVR (Neutron replacement for Nova multi-host)</div><div>* Document Open Source Options</div><div>* Real world (not in gate) performance, stability and scalability testing (performance parity with nova-networking).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>
<br></div><div>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.</div>
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div> </div></div></blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
</div><div class="gmail_extra"><div><div><span style="color:rgb(34,34,34)"> </span><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div><div><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>On 08/05/2014 07:28 PM, Joe Gordon wrote:<br>
><br>
><br>
><br>
> On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a><br>
</div><div><div>> <mailto:<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>>> wrote:<br>
><br>
> On 8/4/14, 4:27 PM, Mark McClain wrote:<br>
>> All-<br>
>><br>
>> tl;dr<br>
>><br>
>> * Group Based Policy API is the kind of experimentation we be<br>
>> should attempting.<br>
>> * Experiments should be able to fail fast.<br>
>> * The master branch does not fail fast.<br>
>> * StackForge is the proper home to conduct this experiment.<br>
> The disconnect here is that the Neutron group-based policy sub-team<br>
> that has been implementing this feature for Juno does not see this<br>
> work as an experiment to gather data, but rather as an important<br>
> innovative feature to put in the hands of early adopters in Juno and<br>
> into widespread deployment with a stable API as early as Kilo.<br>
><br>
><br>
> The group-based policy BP approved for Juno addresses the critical<br>
> need for a more usable, declarative, intent-based interface for<br>
> cloud application developers and deployers, that can co-exist with<br>
> Neutron's current networking-hardware-oriented API and work nicely<br>
> with all existing core plugins. Additionally, we believe that this<br>
> declarative approach is what is needed to properly integrate<br>
> advanced services into Neutron, and will go a long way towards<br>
> resolving the difficulties so far trying to integrate LBaaS, FWaaS,<br>
> and VPNaaS APIs into the current Neutron model.<br>
><br>
> Like any new service API in Neutron, the initial group policy API<br>
> release will be subject to incompatible changes before being<br>
> declared "stable", and hence would be labeled "experimental" in<br>
> Juno. This does not mean that it is an experiment where to "fail<br>
> fast" is an acceptable outcome. The sub-team's goal is to stabilize<br>
> the group policy API as quickly as possible, making any needed<br>
> changes based on early user and operator experience.<br>
><br>
> The L and M cycles that Mark suggests below to "revisit the status"<br>
> are a completely different time frame. By the L or M cycle, we<br>
> should be working on a new V3 Neutron API that pulls these APIs<br>
> together into a more cohesive core API. We will not be in a position<br>
> to do this properly without the experience of using the proposed<br>
> group policy extension with the V2 Neutron API in production.<br>
><br>
><br>
> If we were failing miserably, or if serious technical issues were<br>
> being identified with the patches, some delay might make sense. But,<br>
> other than Mark's -2 blocking the initial patches from merging, we<br>
> are on track to complete the planned work in Juno.<br>
><br>
> -Bob<br>
><br>
><br>
><br>
> As a member of nova-core, I find this whole discussion very startling.<br>
> Putting aside the concerns over technical details and the pain of having<br>
> in tree experimental APIs (such as nova v3 API), neutron still isn't the<br>
> de-facto networking solution from nova's perspective and it won't be<br>
> until neutron has feature and performance parity with nova-network. In<br>
> fact due to the slow maturation of neutron, nova has moved nova-network<br>
> from 'frozen' to open for development (with a few caveats). So unless<br>
> this new API directly solves some of the gaps in [0], I see no reason to<br>
> push this into Juno. Juno hardly seems to be the appropriate time to<br>
> introduce a new not-so-stable API; Juno is the time to address all the<br>
> gaps [0] and hit feature and performance parity with nova-network.<br>
><br>
><br>
> [0]<br>
> <a href="https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage" target="_blank">https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage</a><br>
<br>
</div></div>I would agree.<br>
<br>
There has been a pretty regular issue with Neutron team members working<br>
on new features instead of getting Neutron to feature parity with Nova<br>
network so we can retire the thing. This whole push for another API at<br>
this stage makes no sense to me.<br>
<span><font color="#888888"><br>
-Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
</font></span><div><div><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div>Kevin Benton</div>
</font></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>