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 __________________________________________________________________________ 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
