Manila uses "project_id"s in URLs as Cinder does. So, the same amount of work for each of projects is required.
On Fri, Dec 4, 2015 at 3:29 AM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote: > > > 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 > -- Kind Regards Valeriy Ponomaryov www.mirantis.com vponomar...@mirantis.com
__________________________________________________________________________ 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
