[openstack-dev] [Nova] Support for Pecan in Nova
doug.hellmann at dreamhost.com
Thu Dec 12 16:07:01 UTC 2013
On Wed, Dec 11, 2013 at 6:29 PM, Christopher Yeoh <cbkyeoh at gmail.com> wrote:
> On Thu, Dec 12, 2013 at 7:11 AM, Ryan Petrello <
> ryan.petrello at dreamhost.com> wrote:
>> I’ve spent the past week experimenting with using Pecan for Nova’s API,
>> and have opened an experimental review:
>> …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
> 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. :-)
>> 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).
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev