<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 30, 2013 at 10:16 PM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cyeoh@au1.ibm.com" target="_blank">cyeoh@au1.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Wed, 24 Apr 2013 13:32:50 +0930<br>
<a href="mailto:cyeoh@ozlabs.au.ibm.com">cyeoh@ozlabs.au.ibm.com</a> wrote:<br>
<br>
> On Tue, 23 Apr 2013 19:24:31 -0700<br>
> Doug Hellmann <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>> wrote:<br>
><br>
> > On Tue, Apr 23, 2013 at 6:22 PM, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>><br>
> > wrote:<br>
> > ><br>
> > > I would like to see this seriously considered. I also understand<br>
> > > that it's more work and those driving the v3 API want to make sure<br>
> > > it gets completed. What do you guys think? How much extra work<br>
> > > would this be? Would recruiting someone else to help make it<br>
> > > manageable?<br>
> > ><br>
> ><br>
> > I'm available to at least offer advice about getting started,<br>
> > debugging, and code reviews. I should have some cycles for coding in<br>
> > a few weeks, too.<br>
> ><br>
><br>
> As Russell mention my main concern would be making sure we get the<br>
> v3 API work complete during the Havana cycle. And we do have the extra<br>
> constraint at the start of needing to get the new extension framework<br>
> in before the extensions can be ported to the v3 area as well as<br>
> needing to leave enough time near the end of the havana cycle for the<br>
> tempest tests to be ported as well.<br>
><br>
> That being said I'm quite open to the idea if its going to make things<br>
> better in the long term. I don't know much about it - is there<br>
> anything you can suggest I look at to get up to speed with Pecan/WSME?<br>
<br>
</div>I've had a look at Pecan/WSME and whilst it does seem the right way to<br>
head long term I am still concerned about how taking this on would<br>
impact getting the rest of the v3 API work implemented on schedule and<br>
I think I would need a reasonable amount of help getting the initial<br>
core support for Pecan/WSME done by someone who is very familiar with<br>
them to keep on track. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The goal is to get the new API extension framework in by H1 (end of<br>
May) with just support for the core API functionality and some example<br>
extensions along with unittests. The idea is at that point onwards we<br>
can have a few people easily working parallel to port the rest of the<br>
API extensions (and associated tests).<br></blockquote><div><br></div><div>Are you building a completely new API implementation for Nova, or just modifying the way extensions work?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
>From my understanding of what a Pecan/WSME conversion would involve it<br>
is pretty much orthogonal to the rework/fixup of the API but there are<br>
some gains to be had from doing the framework changes for extensions<br>
and API changes at the same time as the the Pecan/WSME changes. But<br>
strictly speaking it wouldn't be necessary as it won't change the API<br>
itself.<br></blockquote><div><br></div><div style>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.</div><div><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So what I suggest is that if someone else is happy to step up and drive<br>
the integration of Pecan/WSME support with the new extensions framework<br>
for the v3 API and the core of the v3 API with the h1 target date then<br>
I'm more than happy to help and work with them to achieve that. But we<br>
need to keep the h1 target date to keep the rest of the api work on<br>
schedule.</blockquote><div><br></div><div style>I agree that the schedule is important.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
If no one has the time at the moment to do that then it should be<br>
possible to do the Pecan/WSME conversion later, but it will be a big<br>
chunk of work that may be difficult to introduce in reasonably small<br>
chunks.<br></blockquote><div><br></div><div style>Pecan will completely replace the existing WSGI framework, so I'm not quite sure how it would work to do it in chunks.</div><div style><br></div><div style>Doug</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
How does that sound?<br>
<br>
Regards,<br>
<br>
Chris<br>
<span class=""><font color="#888888">--<br>
<a href="mailto:yeohc@au1.ibm.com">yeohc@au1.ibm.com</a><br>
</font></span><div class=""><div class="h5"><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>