[openstack-dev] [neutron] PTL candidacy

Neil Jerram neil at tigera.io
Wed Jan 25 12:55:24 UTC 2017


On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez <thierry at openstack.org>
wrote:

> Kevin Benton wrote:
> > [...]
> > 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.
>
> +1000 on this being a major problem in Neutron. Happy to see that you
> want to work on trying to reduce it.


The Neutron API is a model of what forms of connectivity can be expressed,
between instances and the outside world.  Once that model is chosen, it is
inevitably (and simultaneously):

(a) overconstraining - in other words, there will be forms of connectivity
that someone could reasonably want, but that are not allowed by the model

(b) underconstraining - in other words, there will be nuances of behaviour,
delivered by a particular implementation, that are arguably within what the
model allows, but (as we're talking about semantics) it would really be
better to revise the API so that it can explicitly express those nuances.

Sometimes - since the semantics of the Neutron API are not precisely
documented - it's not clear which of these situations one is in.  But I
think that the point that Sukhdev raised - about other networking projects
being suggested because of Neutron being perceived as not flexible enough -
is to do with (a); whereas the points that Kevin and Thierry responded with
- ways that the API is already _too_ flexible - are to do with (b).  So I'm
not sure that Kevin and Thierry's answers address Sukhdev's point.

It's possible for an API to have (a) and (b) problems simultaneously, and
to make progress on addressing them both.  In Neutron's case, a major
example of (a) has been the routed networks work, which (among other
things) generalized Neutron's network concept from being something that
always provides L2 adjacency between its ports, to something that may or
may not.  So it seems to me that Neutron is able to address (a) problems.
 (I'm personally less familiar with (b), but would guess that progress is
being made there too.)

Regards,
     Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170125/70fb16d9/attachment.html>


More information about the OpenStack-dev mailing list