Open Stack

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:
>
>> 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
> 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/9229e1ea/attachment.html>