<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jan 13, 2014 at 11:15 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 2014-01-13 at 09:40 -0500, Ryan Petrello wrote:<br>
> Jay, I’ll +1 to that.  As I’ve been tinkering with potential Pecan support for the Nova API, I’ve run into the same issue w/ the API composition being seriously complicated (to the point where I’ve realized Pecan isn’t the hard part, it’s the bunch of cruft you need to tie in Pecan/Routes/Falcon/<fill in WSGI framework here>).<br>

<br>
</div>Indeed. And don't get me wrong... I'm not at all saying that Chris is to<br>
blame for anything (or any one person in particular). Just pointing out<br>
that, IMO, the usefulness of API extensions is outweighed by the added<br>
complexity and churn that they bring with them.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>So whilst not supporting API extensions would make things simpler for us, it does have some implications. <br><br>We have around 50+ plugins and only slightly more than 10 are considered to be "core". So with a static API we'd have to have what I think would be a pretty long discussion about what functionality we will no longer support, and inevitably we'll end up with a much larger subset of existing functionality that all Openstack deployers would have to support. Including perhaps all the backend requirements as having an API which doesn't actually work is I don't think an improvement for client programs on not offering the API functionality for a deployment in the first place.<br>
<br></div><div>The other issue is how often with a static API we would have to do version bumping. Icehouse is not unique in having the Nova API extended in several areas and I doubt Juno would be any different. So I expect even if we decided we could simply say "no" to new features more often, with a static API we'll be releasing a new API version every release for the forseable future - what sort of impact does that have on deployers and users?<br>
<br></div><div>I think this effect is magnified with continuous deployment. With a static API and no ability to not immediately deploy an extension just merged, do they have to have an API version bump every time an API changing patch lands?<br>
<br></div><div>And although we don't really have an official policy around it, I think the API extension functionality has been used as a way of allowing new functionality into Nova and evaluating it in place before deciding whether or not it becomes a core part of Nova. <br>
<br></div><div>Chris<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
-jay<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> ---<br>
> Ryan Petrello<br>
> Senior Developer, DreamHost<br>
> <a href="mailto:ryan.petrello@dreamhost.com">ryan.petrello@dreamhost.com</a><br>
><br>
> On Jan 13, 2014, at 9:23 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
><br>
> > On Sun, 2014-01-12 at 19:52 -0800, Christopher Yeoh wrote:<br>
> >> On my phone so will be very brief but perhaps the extensions extension<br>
> >> could publish the jsonschema(s) for the extension. I think the only<br>
> >> complicating  factor would be where extensions extend extensions but I<br>
> >> think it's all doable.<br>
> ><br>
> > Am I the only one that sees the above statement as another indication of<br>
> > why API extensions should eventually find their way into the dustbin of<br>
> > OpenStack history?<br>
> ><br>
> > -jay<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>