> On Dec 3, 2015, at 12:06, Sean Dague <s...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev