<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug.hellmann@dreamhost.com" target="_blank">doug.hellmann@dreamhost.com</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 style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
<div class="im">On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <span dir="ltr"><<a href="mailto:ryan.petrello@dreamhost.com" target="_blank">ryan.petrello@dreamhost.com</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">Hello,<br>
<br>
I’ve spent the past week experimenting with using Pecan for Nova’s API, and have opened an experimental review:<br>
<br>
<a href="https://review.openstack.org/#/c/61303/6" target="_blank">https://review.openstack.org/#/c/61303/6</a><br>
<br>
…which implements the `versions` v3 endpoint using pecan (and paves the way for other extensions to use pecan). This is a *potential* approach I've considered for gradually moving the V3 API, but I’m open to other suggestions (and feedback on this approach). I’ve also got a few open questions/general observations:<br>
<br>
1. It looks like the Nova v3 API is composed *entirely* of extensions (including “core” API calls), and that extensions and their routes are discoverable and extensible via installed software that registers itself via stevedore. This seems to lead to an API that’s composed of installed software, which in my opinion, makes it fairly hard to map out the API (as opposed to how routes are manually defined in other WSGI frameworks). I assume at this time, this design decision has already been solidified for v3?<br>
</blockquote><div><br></div></div><div><div style="font-size:small">Yeah, I brought this up at the summit. I am still having some trouble understanding how we are going to express a stable core API for compatibility testing if the behavior of the API can be varied so significantly by deployment decisions. Will we just list each "required" extension, and forbid any extras for a compliant cloud?</div>
</div></div></div></div></blockquote><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 class="gmail_extra"><div class="gmail_quote">
<div>
<div style="font-size:small"><br></div><div style="font-size:small">Maybe the issue is caused by me misunderstanding the term "extension," which (to me) implies an optional component but is perhaps reflecting a technical implementation detail instead?</div>
<span class=""><font color="#888888">
</font></span></div><span class=""><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>Yes and no :-) As Ryan mentions, all API code is a plugin in the V3 API. However, some must be loaded or the V3 API<br>
</div><div>refuses to start up. In nova/api/openstack/__init__.py we have API_V3_CORE_EXTENSIONS which hard codes<br></div><div>which extensions must be loaded and there is no config option to override this (blacklisting a core plugin will result in the<br>
</div><div>V3 API not starting up).<br><br></div><div>So for compatibility testing I think what will probably happen is that we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)<br></div><div>that must be implemented and clients can rely on that always being present on a compliant cloud. But clients can also then query through /extensions what other functionality (which is backwards compatible with respect to core) may also be present on that specific cloud.<br>
<br></div><div>Chris<br></div><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 class="gmail_extra"><div class="gmail_quote">
<span class=""><font color="#888888"><div></div><div><div style="font-size:small">Doug</div><br></div></font></span><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. The approach in my review would allow us to translate extensions to pecan piecemeal. To me, this seems like a more desirable and manageable approach than moving everything to pecan at once, given the scale of Nova’s API. Do others agree/disagree? Until all v3 extensions are translated, this means the v3 API is composed of two separate WSGI apps.<br>
<br>
3. Can somebody explain the purpose of the wsgi.deserializer decorator? It’s something I’ve not accounted for yet in my pecan implementation. Is the goal to deserialize the request *body* from e.g., XML into a usable data structure? Is there an equivalent for JSON handling? How does this relate to the schema validation that’s being done in v3?<br>
<br>
---<br>
Ryan Petrello<br>
Senior Developer, DreamHost<br>
<a href="mailto:ryan.petrello@dreamhost.com" target="_blank">ryan.petrello@dreamhost.com</a><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
</blockquote></div></div><br></div></div>
<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></blockquote></div><br></div></div>