Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140807/bb393809/attachment.html>