[openstack-dev] Project-Scoped Service Catalog Entries

Jay Pipes jaypipes at gmail.com
Tue Dec 17 01:59:10 UTC 2013

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 at 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...


More information about the OpenStack-dev mailing list