<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 6:29 PM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Thu, Dec 12, 2013 at 7:11 AM, 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: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 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>Yes, from an implementation view everything is an "extension", even core functionality. One issue with the V2 API is that because core is hard coded and separate from the plugin framework there were things you could do in core API code that you couldn't do in extensions and other things which you could do in both, but had to do in different ways. Which is bad from a maintainability/readability point of view. And inevitably we ended up with extension specific code sitting in what should have been only core code. So we ended up deciding to make everything a plugin to consistency of how API code is written and also ensured that the framework didn't treat core API code in any special way.<br>
</div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">OK, I can completely see how that problem would lead to this solution. I'll try to keep that in mind, and start thinking of "extension" in the way it is actually used. :-)</div>
<div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div><br></div><div> </div><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"><div>
</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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></blockquote><div><br></div></div><div>Yes, I think this is the way to go. Attempting to get a big-bang patch merged would be rather challenging. <br></div><div class="im"><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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></blockquote><div><br></div></div><div>Yes the deserializer decorator specifies and XML deserializer which is used when the default one is not suitable. schema validation is done on the deserialized output so essentially covers both JSON and XML (eg XML is not directly validated, but what we end up interpreting in the api code is).<br>
</div><div><br></div><div>Chris<br></div><br></div></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>