[openstack-dev] [neutron] API models [was: PTL candidacy]

Ian Wells ijw.ubuntu at cack.org.uk
Thu Jan 26 03:22:22 UTC 2017


On 25 January 2017 at 18:07, Kevin Benton <kevin at benton.pub> wrote:

> >Setting aside all the above talk about how we might do things for a
> moment: to take one specific feature example, it actually took several
> /years/ to add VLAN-aware ports to OpenStack.  This is an example of a
> feature that doesn't affect or interest the vast majority of the user
> community
>
> Now that it has been standardized on, other services can actually use it
> to build things (e.g. Kuryr, Octavia). If each vendor just went and wrote
> up their own extension for this, no project could reliably build anything
> on top of it that would work with multiple backend vendors.
>

In the weirdest way, I think we're agreeing.  The point is that the API
definition is what matters and the API definition is what we have to
agree.  That means that we should make it easy to develop the API
definition so that we can standardise it promptly, and it also means that
we would like to have the opportunity to agree that extensions are
'standard' (versus today - write an extension attribute that works for you,
call the job done).  It certainly doesn't remove that standardisation step,
which is why I say that governance, here is key - choosing wisely the
things we agree are standards.

To draw an IETF parallel for a moment, it's easy to write and implement a
networking protocol - you need no help or permission - and easy to submit a
draft that describes that protocol.  It's considerably harder to turn that
draft into an accepted standard.

>and perhaps we need a governance model around ensuring that they are sane
> and resuable.
> >Gluon, specifically, is about solving exclusively the technical question
> of how to introduce independent APIs
>
> Doesn't that make Gluon support the opposite of having a governance model
> and standardization for APIs?
>

No.  If you want an in-house API then off you go, write your own.  If you
want to experiment in code, off you go, experimentation is good.  This is
why it should be easy to do.  The easier it is, the more Neutron work
you'll have time for, in fact.

But I can't unilaterally make something standard by saying it is, and
that's where the community can and should get involved.  You have a team of
core devs that can examine those proposed APIs - which are in a simple DSL
- and decide if they should be added to a repository, which you can look at
as an approval step when you decide they're worthy.

Making it hard to write an API is putting a barrier to entry and
experimentation in the way.  Making it hard to standardise that API - by,
for instance, putting technical requirements on it that it be supportable
and maintainable, generally usable and of no impact to people who don't use
it - that's far more useful.

We can't stop people writing bad APIs.  What we have in place today doesn't
stop that, as made by the Contrail point previously.  But that has no
relevance to the difficulty of writing APIs, which slows down both good and
bad implementations equally.


> >I do not care if we make Neutron extensible in some different way to
> permit this, if we start a new project or whatever, I just want it to
> happen.
>
> I would like to promote experimentation with APIs with Neutron as well,
> but I don't think it's ever going to be as flexible as the
> configuration-defined behavior Gluon allows.
>

You refer to it as 'configuration defined' but the API description is not a
configuration language to be changed on a whim by the end user - it's a
DSL, it's code (of a sort), it's a part of the thing you ship.


> My goal is getting new features that extend beyond one backend and without
> some community agreement on new APIs, I don't see how that's possible.
>

Again, I agree with this.  But again - one way of making standards is to
have a documented standard and two independent implementations.  We don't
see that today because that would be a huge effort.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170125/a88c9af6/attachment.html>


More information about the OpenStack-dev mailing list