Open Stack

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.gordon0 at gmail.com> wrote:

>
>
>
> On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton <blak111 at 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 <sean at dague.net> wrote:
>>
>>> On 08/05/2014 07:28 PM, Joe Gordon wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <
>>> kukura at noironetworks.com
>>> > <mailto:kukura at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Kevin Benton
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/3a0fc1f2/attachment.html>