Open Stack

On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton <kevin at benton.pub> wrote:

> >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....
>
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever behavior
> they want. This is great for vendors because they can directly expose
> features without having to make them vendor agnostic. However, it's
> terrible for operators because it leads to lock-in and terrible for the
> users because it leads to cross-cloud compatibility issues.
>
> For a concrete example of what I mean, take a look at this extension here:
> [1]. This is directly exposing vendor-specific things onto Neutron network
> API payloads. Nobody can build any tooling that depends on those fields
> without being locked into a specific vendor.
>

I do not believe this is a good example. I believe this is for monolithic
plugin (and probably pre-ML2 plugin time frame). If memory serves me right,
there were no specific guidelines at the time. I am sure there are many
other such examples relating to monolithic plugins.
However, I do get your point. Hence, the need to have a good look at the
API so that it can provide way for vendors and operators to expose the
strengths/features of their back-ends in a vendor agnostic fashion.

-Sukhdev



> So what I would like to encourage is bringing API extension work into
> Neutron-lib where we can ensure that the relevant abstractions are in place
> and it's not just a pass-through to a bunch of vendor-specific features. I
> would rather relax our constraint around requiring a reference
> implementation for new extensions in neutron-lib than continue to encourage
> developers to do expose whatever they want with the the existing extension
> framework.
>
> So I'm all for developing new APIs *as a community* to enable NFV use
> cases not supported by the current APIs. However, I don't want to encourage
> or make it easier for vendors to just build arbitrary extensions on top of
> Neutron that expose backend details.
>
> In my view, Neutron should provide a unified API for networking across
> OpenStack clouds, not a platform for writing deployment-specific networking
> APIs.
>
> 1. https://github.com/Juniper/contrail-neutron-plugin/blob/1
> 9ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contr
> ail/extensions/contrail.py#L9-L22
>
> Cheers,
> Kevin Benton
>
> 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.op
>>> enstack.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:unsubscrib
>> e
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170125/229f96ab/attachment.html>