Open Stack

>This is why it should be easy to do.  The easier it is, the more Neutron
work you'll have time for, in fact.

I agree that writing them should be easy. But I don't want to enable
operators to just tweak config files to alter APIs. So +1000 to developer
productivity. I just don't want it to circumvent sane API reviews.

>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.

This sounds good. What I want to ensure is that step of review between the
experimentation bit and operators using it bit.

>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.

Agree.

>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.

It's configuration defined in the sense that two people using gluon source
from different YAML configurations can end up with APIs that are completely
different and incompatible. That's problematic from an API user's
perspective because "this operator uses gluon" is sort of a useless
statement for understanding how to interact with the system.


>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.

Requiring two implementations is definitely something I don't want to
require. I would rather agree upon and accept experimental APIs that only
have one implementation than have a vendor do it on their own. It's usually
pretty easy to recognize when things are getting too vendor-specific even
if you don't have the implementation to test with.

On Wed, Jan 25, 2017 at 7:22 PM, Ian Wells <ijw.ubuntu at cack.org.uk> wrote:

> 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.
>
> __________________________________________________________________________
> 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/29b5a3f7/attachment.html>