Open Stack

Catching up on the thread, lots of good thoughts.

I don't think there is disagreement here around how Networking API
should evolve in terms of vendor extensions. As Kevin suggested, we
don't want to advertise API extensibility without Neutron team
supervision.

One of the reasons behind current api-ref effort that includes moving
API definitions from all stadium projects into neutron-lib - and
vouching for new API changes in scope of this single repo - is to
transform Neutron from a shallow API controller that allows to plug in
opaque API modules into a single API with consistent behavior, review
practices and standards.

I would go as far as to say that once that effort is complete, we
should start looking for ways to discourage (if not forbid) API
pluggability not proxied through proper in-neutron-lib review process.
It's one thing to allow plugging in different networking backends that
all implement the same Networking API behavior; and it's completely
different to allow those plugins to change Networking API to the point
where you can't even tell if it's open API guaranteed to work in other
environments.

Yes, there is concern that Networking API doesn't move as quick as
some vendors may want. We can address that with streamlining review
process for new API definitions. As long as an API proposal makes
sense not just for one specific backend, and is defined in general
enough terms, I think we can go with expedited review procedure.
Indeed we should probably reconsider how we enforce reference
implementation completion before an extension is allowed in.

Ihar

On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur <sukhdevkapur at gmail.com> wrote:
>
> Ihar and Kevin,
>
> As our potential future PTLs, I would like to draw your attention to one of
> the critical issue regarding Neutron as "the" networking service in
> OpenStack.
>
> I keep hearing off and on that Neutron is not flexible to address many
> networking use cases and hence a new (or additional) networking project is
> needed. For example, to address the use cases around NFV (rigid resource
> inter-dependencies).  Another one keeps popping up is that it is very
> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
> called out in Ihar's candidacy.
>
> I would really like us to discuss this issue head-on and see what is missing
> in Neutron APIs and what would take to make them extensible so that vendors
> do not run around trying to figure out alternative solutions....
>
> cheers..
> -Sukhdev
>
>
>
>>
>> * Explore alternative ways to evolve Neutron API.  Piling up
>> extensions and allowing third parties to completely change core
>> resource behaviour is not ideal, and now that api-ref and API
>> consolidation effort in neutron-lib are closer to completion, we may
>> have better answers to outstanding questions than during previous
>> attempts to crack the nut. I would like to restart the discussion some
>> time during Pike.
>
>
>
>
>>
>>
>> Thanks for attention,
>> Ihar
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>