Open Stack

On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton <gkotton at vmware.com> wrote:
> Correct, this work is orthogonal to the parity work, which I understand is
> coming along very nicely.

Agree Gary and Kevin. I think the topic of Nova integration has
created confusion in people’s mind (at least the non-Neutron folks)
with regards to what is being proposed in the Group-based Policy (GBP)
feature. So to clarify - GBP is an optional extension, like many other
existing Neutron extensions. It is not meant to replace the Neutron
core API and/or the current Nova-Neutron interaction in Juno.

> 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>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Wednesday, August 6, 2014 at 9:12 AM
>
> To: OpenStack List <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> 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
>