Open Stack

Correct, this work is orthogonal to the parity work, which I understand is coming along very nicely. 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 <blak111 at gmail.com<mailto:blak111 at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 9:12 AM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at 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 <sean at dague.net<mailto: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>
> <mailto: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<https://urldefense.proofpoint.com/v1/url?u=http://dague.net&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=lqfJNxqJLQC4hxj6J607y0jRZzrMwZl06mHypsIU5Vg%3D%0A&s=b313bb900f21d3dbd2d6e9a28f7bb2e3b23f3d8b35a9a0fff77a151a5400e768>

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/2e0b05f2/attachment.html>