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