Open Stack

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 <jim at jimrollenhagen.com>
wrote:

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



-- 
Kind Regards
Valeriy Ponomaryov
www.mirantis.com
vponomaryov at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151204/bab22e5d/attachment.html>