<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jan 14, 2014 at 10:59 AM, 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"><br>
We don't need API extensions and they make our Compute API laughably<br>
complex and cumbersome. We should ditch entirely the concept of API<br>
extensions in our next Compute API major release.<br>
<br></blockquote><div><br></div><div>I think it way too late in the cycle to make this sort of change for the V3 API.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
admin_actions -- seriously...why wouldn't pause/unpause, etc be part of<br>
the API? if some hypervisor doesn't support the action, then raise<br>
NotImplemented and return an HTTP 501 Not Implemented -- after all,<br>
that's what a 501 was designed for, and client tooling for HTTP APIs<br>
should understand that.<br>
<br></blockquote><div><br></div><div>So interestingly the feedback we got at the HK design summit session around admin_actions<br>is that we should split it up into multiple smaller extensions (and this is going through<br>
now). So deployers could more selectively deploy what they want to and not include what<br>they don't want.<br></div><div class="im"> <br>
> And although we don't really have an official policy around it, I<br>
> think the API extension functionality has been used as a way of<br>
> allowing new functionality into Nova and evaluating it in place before<br>
> deciding whether or not it becomes a core part of Nova.<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do understand this. But, I just think that it's mainly laziness that<br>
drives this. Instead of doing the hard work of determining a useful API<br>
structure ahead of time -- and validating that the new features actually<br>
fit the API audience -- it's just one more way of pushing immature or<br>
ill-fitting code into a codebase.<br>
<br>
Sorry for ranting.<br>
<br></blockquote><div><br></div><div>Ranting is fine with me :-) But if its something we wanted to do for the V3 API we really should<br></div><div>have had this sort of discussion at the *Havana* design summit.<br><br></div>
<div>FWIW I think we're getting a lot better at doing quality control on APIs which are added.<br></div><div><br></div><div>Chris<br></div></div></div></div>