Hi All:

+1 Ivar. Yes the timing of the alternate proposal does make the notion of spec 
reviews seem like a process tick mark with no seeming benefit. It is indeed 
unfair to the folks who have put in a lot of effort with an approved spec to 
have a workflow change pulled on them so late in the cycle.



From: Ivar Lazzaro <ivarlazz...@gmail.com<mailto:ivarlazz...@gmail.com>>
Reply-To: OpenStack List 
Date: Wednesday, August 6, 2014 at 12:01 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova Parity 
for the Juno release? Because then I fail to see why this and Mark's proposal 
are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP approval 
time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in 
Neutron (which basically is a workflow change), we should discuss all of it for 
the next release without blocking patches which went through the whole approval 
process and are ready to be merged after community effort (BP process, Weakly 
meetings, POC, reviews). Just like has been done in other similar cases (eg. 
3rd Party CI). This of course is IMHO.


On Aug 6, 2014 4:55 PM, "Joe Gordon" 
<joe.gord...@gmail.com<mailto:joe.gord...@gmail.com>> wrote:

On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton 
<blak...@gmail.com<mailto: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<mailto: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>
> <mailto: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 Dague

OpenStack-dev mailing list

Kevin Benton

OpenStack-dev mailing list

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to