Open Stack

Since the response seems quite positive, here's a stub blueprint for it: https://blueprints.launchpad.net/nova/+spec/v3-api-remove-project-id

Feel free to triage, prioritize, etc. as appropriate. :-)

    - Gabriel

> -----Original Message-----
> From: Christopher Yeoh [mailto:cbkyeoh at gmail.com]
> Sent: Thursday, May 09, 2013 7:31 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Remove tenant/project ID from Nova v3 API
> URLs
> 
> 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev