<div dir="ltr">><span style="font-size:12.8px">This is why it should be easy to do.  The easier it is, the more Neutron work you'll have time for, in fact.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This sounds good. What I want to ensure is that step of review between the experimentation bit and operators using it bit.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div>Agree.</div><div><br></div><div>><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div><div><br></div><div><br></div><div>><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 7:22 PM, Ian Wells <span dir="ltr"><<a href="mailto:ijw.ubuntu@cack.org.uk" target="_blank">ijw.ubuntu@cack.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 25 January 2017 at 18:07, Kevin Benton <span dir="ltr"><<a href="mailto:kevin@benton.pub" target="_blank">kevin@benton.pub</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><span class="m_5461969390077033098gmail-"></span><span class="m_5461969390077033098gmail-"><div dir="auto">>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</div></span><span class="m_5461969390077033098gmail-"><div dir="auto"><br></div></span><div>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.</div></div></div></blockquote><div><br></div></span><div>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.<br><br></div><div>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.<br></div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><span class="m_5461969390077033098gmail-"><div></div><div>>and perhaps we need a governance model around ensuring that they are sane and resuable.</div></span><span class="m_5461969390077033098gmail-"><div>>Gluon, specifically, is about solving exclusively the technical question of how to introduce independent APIs</div><div><br></div></span><div>Doesn't that make Gluon support the opposite of having a governance model and standardization for APIs? </div></div></div></blockquote><div><br></div></span><div>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.<br><br>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.<br></div><div><br></div><div>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.<br><br></div><div>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.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><span class="m_5461969390077033098gmail-"><div></div><div>>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.</div><div><br></div></span><div>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.</div></div></div></blockquote><div><br></div></span><div>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.<br></div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="auto"><div>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.</div></div></div></blockquote><div><br></div></span><div>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.<span class="HOEnZb"><font color="#888888"><br>-- <br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Ian.<br></div></font></span></div></div></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>