Open Stack

On 12/16/2013 04:17 PM, Georgy Okrokvertskhov wrote:
> By they way, there is an initiative to create generic metadata
> repository based on Glance project. As services endpoints are just URLs
> they also can be stored in this Glance metadata repository and have all
> features related to visibility and access control provides by this
> repository.

Well, hold on there :) The proposed enhancements to Glance for a generic 
application metadata repository are a bit different from a service 
catalog, for one main reason: the service catalog is returned by 
Keystone in the Keystone token, and the service catalog will be [1] 
scoped to the owner of the token that was authenticated by Keystone.

I think because of the current relationship between the service catalog 
actually being within the construct of a returned Keystone token, 
Keystone, at least for the foreseeable future, is the appropriate place 
to do this kind of project-scoped service catalog.

I'm actually pretty familiar with the code in Keystone, and I was 
planning on implementing the proper region resource in the 3.2 API [2]. 
I would not mind doing the coding on Gabe's proposed project-scoped 
catalog once [1] has been implemented (API spec: [3]).

Best,
-jay

[1] https://blueprints.launchpad.net/keystone/+spec/service-scoped-tokens
[2] https://review.openstack.org/#/c/54215/
[3] https://review.openstack.org/#/c/61869/

> On Mon, Dec 16, 2013 at 12:21 PM, Tim Bell <Tim.Bell at cern.ch
> <mailto:Tim.Bell at cern.ch>> wrote:
>
>
>     +1
>
>     There is also the use case where a new service is being introduced
>     for everyone eventually but you wish to start with a few friends. In
>     the event of problems, the effort to tidy up is much less.
>     Documentation can be updated with the production environment.
>
>     Tim
>
>      > -----Original Message-----
>      > From: Gabriel Hurley [mailto:Gabriel.Hurley at nebula.com
>     <mailto:Gabriel.Hurley at nebula.com>]
>      > Sent: 16 December 2013 20:58
>      > To: OpenStack Development Mailing List
>     (openstack-dev at lists.openstack.org
>     <mailto:openstack-dev at lists.openstack.org>)
>      > Subject: [openstack-dev] Project-Scoped Service Catalog Entries
>      >
>      > I've run into a use case that doesn't currently seem to have a
>     great solution:
>      >
>      >
>      > Let's say my users want to use a "top-of-stack" OpenStack project
>     such as Heat, Trove, etc. that I don't currently support in my
>      > deployment. There's absolutely no reason these services can't
>     live happily in a VM talking to Nova, etc. via the normal APIs.
>     However, in
>      > order to have a good experience (Horizon integration, seamless
>     CLI integration) the service needs to be in the Service Catalog. One
>     user
>      > could have their service added to the catalog by an admin, but
>     then everyone in the cloud would be using their VM. And if you have
>      > multiple users all doing the same thing in their own projects,
>     you've got collisions!
>      >
>      >
>      > So, I submit to you all that there is value in having a way to
>     scope Service Catalog entries to specific projects, and to allow
>     users with
>      > appropriate permissions on their project to add/remove those
>     project-level service catalog entries.
>      >
>      > This could be accomplished in a number of ways:
>      >
>      >   * Adding a new field to the model to store a Project ID.
>      >   * Adding it in a standardized manner to "service metadata" as
>     with https://blueprints.launchpad.net/keystone/+spec/service-metadata
>      >   * Adding it as an "additional requirement" as proposed by
>     https://blueprints.launchpad.net/keystone/+spec/auth-mechanisms-for-
>      > services
>      >   * Use the existing Region field to track project scope as a hack.
>      >   * Something else...
>      >
>      > I see this as analogous to Nova's concept of per-project flavors,
>     or Glance's private/public/shared image capabilities. Allowing explicit
>      > "sharing" would even be an interesting option for service
>     endpoints. It all depends how far we would want to go with it.
>      >
>      > Feel free to offer feedback or other suggestions.
>      >
>      > Thanks!
>      >
>      >      - Gabriel
>      >
>      > _______________________________________________
>      > OpenStack-dev mailing list
>      > OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>      > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Georgy Okrokvertskhov
> Technical Program Manager,
> Cloud and Infrastructure Services,
> Mirantis
> http://www.mirantis.com <http://www.mirantis.com/>
> Tel. +1 650 963 9828
> Mob. +1 650 996 3284
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>