<div dir="ltr">By they way, there is an initiative to create generic metadata repository based on Glance project. As services endpoints are just URLs they also can be stored in this Glance metadata repository and have all features related to visibility and access control provides by this repository.<div>
<br></div><div>Thanks</div><div>Georgy</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 16, 2013 at 12:21 PM, Tim Bell <span dir="ltr"><<a href="mailto:Tim.Bell@cern.ch" target="_blank">Tim.Bell@cern.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
+1<br>
<br>
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.<br>

<span class="HOEnZb"><font color="#888888"><br>
Tim<br>
</font></span><div class="im HOEnZb"><br>
> -----Original Message-----<br>
> From: Gabriel Hurley [mailto:<a href="mailto:Gabriel.Hurley@nebula.com">Gabriel.Hurley@nebula.com</a>]<br>
> Sent: 16 December 2013 20:58<br>
> To: OpenStack Development Mailing List (<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>)<br>
> Subject: [openstack-dev] Project-Scoped Service Catalog Entries<br>
><br>
</div><div class="HOEnZb"><div class="h5">> I've run into a use case that doesn't currently seem to have a great solution:<br>
><br>
><br>
> 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<br>
> 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<br>
> order to have a good experience (Horizon integration, seamless CLI integration) the service needs to be in the Service Catalog. One user<br>
> 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<br>
> multiple users all doing the same thing in their own projects, you've got collisions!<br>
><br>
><br>
> 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<br>
> appropriate permissions on their project to add/remove those project-level service catalog entries.<br>
><br>
> This could be accomplished in a number of ways:<br>
><br>
>   * Adding a new field to the model to store a Project ID.<br>
>   * Adding it in a standardized manner to "service metadata" as with <a href="https://blueprints.launchpad.net/keystone/+spec/service-metadata" target="_blank">https://blueprints.launchpad.net/keystone/+spec/service-metadata</a><br>

>   * Adding it as an "additional requirement" as proposed by <a href="https://blueprints.launchpad.net/keystone/+spec/auth-mechanisms-for-" target="_blank">https://blueprints.launchpad.net/keystone/+spec/auth-mechanisms-for-</a><br>

> services<br>
>   * Use the existing Region field to track project scope as a hack.<br>
>   * Something else...<br>
><br>
> I see this as analogous to Nova's concept of per-project flavors, or Glance's private/public/shared image capabilities. Allowing explicit<br>
> "sharing" would even be an interesting option for service endpoints. It all depends how far we would want to go with it.<br>
><br>
> Feel free to offer feedback or other suggestions.<br>
><br>
> Thanks!<br>
><br>
>      - Gabriel<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div>