Open Stack

On Tue, Apr 30, 2013 at 10:16 PM, Christopher Yeoh <cyeoh at au1.ibm.com>wrote:

> On Wed, 24 Apr 2013 13:32:50 +0930
> cyeoh at ozlabs.au.ibm.com wrote:
>
> > On Tue, 23 Apr 2013 19:24:31 -0700
> > Doug Hellmann <doug.hellmann at dreamhost.com> wrote:
> >
> > > On Tue, Apr 23, 2013 at 6:22 PM, Russell Bryant <rbryant at redhat.com>
> > > wrote:
> > > >
> > > > I would like to see this seriously considered.  I also understand
> > > > that it's more work and those driving the v3 API want to make sure
> > > > it gets completed.  What do you guys think?  How much extra work
> > > > would this be? Would recruiting someone else to help make it
> > > > manageable?
> > > >
> > >
> > > I'm available to at least offer advice about getting started,
> > > debugging, and code reviews. I should have some cycles for coding in
> > > a few weeks, too.
> > >
> >
> > As Russell mention my main concern would be making sure we get the
> > v3 API work complete during the Havana cycle. And we do have the extra
> > constraint at the start of needing to get the new extension framework
> > in before the extensions can be ported to the v3 area as well as
> > needing to leave enough time near the end of the havana cycle for the
> > tempest tests to be ported as well.
> >
> > That being said I'm quite open to the idea if its going to make things
> > better in the long term. I don't know much about it - is there
> > anything you can suggest I look at to get up to speed with Pecan/WSME?
>
> I've had a look at Pecan/WSME and whilst it does seem the right way to
> head long term I am still concerned about how taking this on would
> impact getting the rest of the v3 API work implemented on schedule and
> I think I would need a reasonable amount of help getting the initial
> core support for Pecan/WSME done by someone who is very familiar with
> them to keep on track.


> The goal is to get the new API extension framework in by H1 (end of
> May) with just support for the core API functionality and some example
> extensions along with unittests. The idea is at that point onwards we
> can have a few people easily working parallel to port the rest of the
> API extensions (and associated tests).
>

Are you building a completely new API implementation for Nova, or just
modifying the way extensions work?


>
> From my understanding of what a Pecan/WSME conversion would involve it
> is pretty much orthogonal to the rework/fixup of the API but there are
> some gains to be had from doing the framework changes for extensions
> and API changes at the same time as the the Pecan/WSME changes. But
> strictly speaking it wouldn't be necessary as it won't change the API
> itself.
>

I apologize for not responding earlier to your request for a review of the
new extension design. I will try to look at it today.

The "rules" imposed by WSME may influence the API design, slightly. It
introduces strong typing in the input arguments and response values from
the API methods. That means you can't always just say "and this value is a
dictionary of whatever we want it to be" (although you can include
dictionaries, you have to declare the types of the keys and values, so it
is often better to use a class to declare all of the fields and set their
types individually). It also means that instead of allowing extensions to
add arbitrary fields, we would need to provide an explicit place in the
response where extension data can go.

Moving to Pecan instead of the Oslo/Nova WSGI framework may also introduce
changes, based on selecting an approach for its ease of implementation. I
would expect those changes to smaller than what WSME might suggest.


>
> So what I suggest is that if someone else is happy to step up and drive
> the integration of Pecan/WSME support with the new extensions framework
> for the v3 API and the core of the v3 API with the h1 target date then
> I'm more than happy to help and work with them to achieve that. But we
> need to keep the h1 target date to keep the rest of the api work on
> schedule.


I agree that the schedule is important.


>
> If no one has the time at the moment to do that then it should be
> possible to do the Pecan/WSME conversion later, but it will be a big
> chunk of work that may be difficult to introduce in reasonably small
> chunks.
>

Pecan will completely replace the existing WSGI framework, so I'm not quite
sure how it would work to do it in chunks.

Doug


>
> How does that sound?
>
> Regards,
>
> Chris
> --
> yeohc at au1.ibm.com
>
>
> _______________________________________________
> 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/20130501/1fd4b45a/attachment.html>