On Wed, Dec 11, 2013 at 6:29 PM, Christopher Yeoh <[email protected]> wrote:
> On Thu, Dec 12, 2013 at 7:11 AM, Ryan Petrello < > [email protected]> wrote: > >> Hello, >> >> I’ve spent the past week experimenting with using Pecan for Nova’s API, >> and have opened an experimental review: >> >> https://review.openstack.org/#/c/61303/6 >> >> …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: >> >> 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? >> > > 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. > 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. :-) Doug > > >> >> 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. >> >> > Yes, I think this is the way to go. Attempting to get a big-bang patch > merged would be rather challenging. > > > >> 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? >> >> > 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). > > Chris > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
