[openstack-dev] [Nova] Support for Pecan in Nova

Christopher Yeoh cbkyeoh at gmail.com
Wed Dec 11 23:36:38 UTC 2013


On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
<doug.hellmann at dreamhost.com>wrote:

>
>
>
> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <
> ryan.petrello at dreamhost.com> 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?
>>
>
> 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?
>

> 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?
>
>
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
refuses to start up. In nova/api/openstack/__init__.py we have
API_V3_CORE_EXTENSIONS which hard codes
which extensions must be loaded and there is no config option to override
this (blacklisting a core plugin will result in the
V3 API not starting up).

So for compatibility testing I think what will probably happen is that
we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)
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.

Chris



> 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.
>>
>> 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?
>>
>> ---
>> Ryan Petrello
>> Senior Developer, DreamHost
>> ryan.petrello at dreamhost.com
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131212/a4afd131/attachment.html>


More information about the OpenStack-dev mailing list