Open Stack

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?

	-Sean

-- 
Sean Dague
http://dague.net