Open Stack

On Thu, 09 May 2013 09:05:41 -0400
Russell Bryant <rbryant at redhat.com> wrote:
> 
> It seems very valuable, so ... high enough priority to include it in
> the v3 API, I guess.  :-)
> 
> I'm not exactly sure what you're asking for.  Would you like to write
> out all of the tasks we have for the v3 API and sort them by priority?
> I'm happy to provide input on that list.
> 
> Perhaps more importantly, if you feel like the list is getting too big
> and risks not getting completed in Havana, let me know.  I'll chase
> down more people to help.  ceyoh seemed to imply this was the case if
> we start adding things (including this) in another message, so I'll
> start asking around.  (Or if you're reading this and would like to
> volunteer, please speak up!)

Schedule-wise the things which concern me the most are those which have
to (or should really) be done before porting of the extensions
can/should occur. So WSME/Pecan was an example of this. Making
extensions specify what errors they expect can occur and explictly set
status codes is another simply because of the size the patch would end
up being if left to late. 

Removing the tenant id is similar but I'm guessing should be a much
much simpler job than the WSME/Pecan proposal. However it still has the
potential to delay the point in time where we can reasonably have a
number of people working in parallel on porting extensions without
having the risk of lots of rebasing work. And I think we have a few
people around willing/wanting to help out.

Mauro and I have been doing some speculative porting work to help flush
out issues with the framework and core ports, but we know we'll
probably have to rebase them a fair amount. Thus if there is someone
available to help look at this specific issue it would be very helpful,
if not I'm guessing either Mauro or I will end up looking at it soonish
since its a high priority thing.

Just to explain why I think the schedule is fairly tight, ideally I
would like to see the vast majority (if not all!) of extensions ported
by the end of h2 to leave us with h3 to get the test coverage up
properly. Because once we release Havana we can't easily make bug fixes
and we don't want to do a V4 API too soon :-) Also it will give us time
to port some of the new extensions developed during Havana as I think we
want to avoid releasing Havana with the V3 API having less
functionality than V2 (except where we are deliberately deprecating
things).

Anyway I'll use this opportunity to again shamelessly plug
review requests for the extension framework patches:

https://review.openstack.org/#/c/27276/
https://review.openstack.org/#/c/28298/

I know there's likely a few small things to fix up, but if possible I
want to avoid someone coming in at the last minute saying the whole
approach is bad and we need to start from scratch again. So anyone out
there who cares a lot about how api extensions will work in V3 please
have a look :-)

Regards,

Chris