<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 13, 2013 at 4:12 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"><div class="im">On 12/11/2013 11:47 PM, Mike Perez wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 10:06 Thu 12 Dec     , Christopher Yeoh wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann<br>
<<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</a><br></div>
<mailto:<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@<u></u>dreamhost.com</a>>>wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <<br>
<a href="mailto:ryan.petrello@dreamhost.com" target="_blank">ryan.petrello@dreamhost.com</a><br></div>
<mailto:<a href="mailto:ryan.petrello@dreamhost.com" target="_blank">ryan.petrello@<u></u>dreamhost.com</a>>><br>
</blockquote></blockquote></blockquote><div><div class="h5">
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
I’ve spent the past week experimenting with using Pecan for<br>
Nova’s<br>
</blockquote></blockquote></blockquote>
API<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

and have opened an experimental review:<br>
<br>
<a href="https://review.openstack.org/#/c/61303/6" target="_blank">https://review.openstack.org/#<u></u>/c/61303/6</a><br>
<br>
…which implements the `versions` v3 endpoint using pecan (and<br>
</blockquote></blockquote></blockquote>
paves the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

way for other extensions to use pecan).  This is a *potential*<br>
<br>
</blockquote></blockquote></blockquote>
approach<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I've considered for gradually moving the V3 API, but I’m open<br>
to other suggestions (and feedback on this approach).  I’ve<br>
also got a few open questions/general observations:<br>
<br>
1.  It looks like the Nova v3 API is composed *entirely* of<br>
extensions (including “core” API calls), and that extensions<br>
and their routes are discoverable and extensible via installed<br>
software that registers<br>
</blockquote></blockquote></blockquote>
itself<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

via stevedore.  This seems to lead to an API that’s composed of<br>
<br>
</blockquote></blockquote></blockquote>
installed<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

software, which in my opinion, makes it fairly hard to map out<br>
the<br>
</blockquote></blockquote></blockquote>
API (as<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

opposed to how routes are manually defined in other WSGI<br>
</blockquote></blockquote></blockquote>
frameworks).  I<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

assume at this time, this design decision has already been<br>
</blockquote></blockquote></blockquote>
solidified for<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

v3?<br>
<br>
</blockquote>
<br>
Yeah, I brought this up at the summit. I am still having some<br>
trouble understanding how we are going to express a stable core<br>
API for compatibility testing if the behavior of the API can be<br>
varied so significantly by deployment decisions. Will we just<br>
list each<br>
</blockquote></blockquote>
"required"<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
extension, and forbid any extras for a compliant cloud?<br>
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Maybe the issue is caused by me misunderstanding the term<br>
"extension," which (to me) implies an optional component but is<br>
perhaps reflecting a technical implementation detail instead?<br>
<br>
<br>
</blockquote>
Yes and no :-) As Ryan mentions, all API code is a plugin in the V3<br>
API. However, some must be loaded or the V3 API refuses to start<br>
up. In nova/api/openstack/__init__.py we have<br>
API_V3_CORE_EXTENSIONS which hard codes which extensions must be<br>
loaded and there is no config option to override this (blacklisting<br>
a core plugin will result in the V3 API not starting up).<br>
<br>
So for compatibility testing I think what will probably happen is<br>
that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS) that<br>
must be implemented and clients can rely on that always being<br>
</blockquote>
present<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
on a compliant cloud. But clients can also then query through<br>
/extensions what other functionality (which is backwards compatible<br>
with respect to core) may also be present on that specific cloud.<br>
</blockquote>
<br>
This really seems similar to the idea of having a router class, some<br>
controllers and you map them. From my observation at the summit,<br>
calling everything an extension creates confusion. An extension<br>
"extends" something. For example, Chrome has extensions, and they<br>
extend the idea of the core features of a browser. If you want to do<br>
more than back/forward, go to an address, stop, etc, that's an<br>
extension. If you want it to play an audio clip "stop, hammer time"<br>
after clicking the stop button, that's an example of an extension.<br>
<br>
In OpenStack, we use extensions to extend core. Core are the<br>
essential feature(s) of the project. In Cinder for example, core is<br>
volume. In core you can create a volume, delete a volume, attach a<br>
volume, detach a volume, etc. If you want to go beyond that, that's<br>
an extension. If you want to do volume encryption, that's an example<br>
of an extension.<br>
<br>
I'm worried by the discrepancies this will create among the programs.<br>
You mentioned maintainability being a plus for this. I don't think<br>
it'll be great from the deployers perspective when you have one<br>
program that thinks everything is an extension and some of them have<br>
to be enabled that the deployer has to be mindful of, while the rest<br>
of the programs consider all extensions to be optional.<br>
</div></div></blockquote>
<br>
+1. I agree with most of what Mike says above. The idea that there are core "extensions" in Nova's v3 API doesn't make a whole lot of sense to me.<br>
<br></blockquote><div><br></div><div>So would it help if we used the term "plugin" to talk about the framework that the API is implemented with,<br>and extensions when talking about things which extend the core API? So the whole of the API is implemented<br>
using plugins, while the core plugins are not considered to be extensions.<br></div><br></div><div class="gmail_quote">Chris<br></div></div></div>