On 12/16/2013 08:39 PM, Adam Young wrote:
On 12/16/2013 02:57 PM, Gabriel Hurley wrote:
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
See the endpoint filtering blueprint from the Havana release as a
starting point. I think the difference between that and what you have
here is that these endpoints should only show up in a subset of the
service catalogs returned?
https://github.com/openstack/keystone/commit/5dc50bbf0fb94506a06ae325d46bcf3ac1c4ad0a
Also note the above is an admin API extension...
-jay
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
