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
-
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
: [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
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
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
On 12/16/2013 08:39 PM, Adam Young wrote:
snip
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?
