[openstack-dev] [all] making project_id optional in API URLs

Jim Rollenhagen jim at jimrollenhagen.com
Fri Dec 4 01:29:06 UTC 2015


> On Dec 3, 2015, at 12:06, Sean Dague <sean at dague.net> wrote:
> 
> For folks that don't know, we've got an effort under way to look at some
> of what's happened with the service catalogue, how it's organically grown,
> and do some pruning and tuning to make sure it's going to support what
> we want to do with OpenStack for the next 5 years (wiki page to dive
> deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG).
> 
> One of the items which came up is removing project_id from API urls.
> Today there is a very odd linkage between keystone service catalog
> entries and project_ids. For instance in Nova every single project has a
> different API endpoint.
> 
> https://nova.api.server/v2.1/$project_id
> 
> That has implications for caching, and exposing this anonymously, and
> having to carry around the whole service catalog in your oslo.context
> (which means putting it over the RPC bus a lot).
> 
> For Nova, this was almost entirely ignored. It turned out to be a pretty
> simple functional change to have a set of routes which don't need them -
> https://review.openstack.org/#/c/233076/6  (it's more involved to have
> comprehensive testing, but we'll ignore that for now).
> 
> Projects that spawned from Nova: Cinder, Glance, Ironic, Manila, Magnum,
> I'm hoping this is just as much of a surface integration that optionally
> dropping it shouldn't be a big deal. However, for any projects that have
> it, if folks could speak up, that would be great. It would also be good
> to know which projects are up for making this kind of change this cycle,
> as certain future work is inhibited until we get this in. We'll be
> landing this in Nova this cycle.
> 
> Swift is a different story, the project_id is a core concept in the
> resources. That's fine, but when we expose a new resource for the
> service catalog tng, we won't be doing the magic substitution on the
> server side. New clients, consuming the new interface, will need to
> construct the urls themselves.
> 
> So, for Cinder, Glance, Ironic, Manila, Magnum (and others I might have
> missed) where are you standing on this one? And are there volunteers in
> those projects to help move this forward?

Ironic today has no concept of tenant/project/etc so should be nothing to do here. :)

// jim 

> 
>    -Sean
> 
> -- 
> Sean Dague
> http://dague.net
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



More information about the OpenStack-dev mailing list