Open Stack

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.

Ivar.
On Aug 6, 2014 4:55 PM, "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/965e4497/attachment.html>