Open Stack

+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]
> Sent: 16 December 2013 20:58
> To: OpenStack Development Mailing List (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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev