<div dir="ltr">If you're saying that you want to register URLs without version info embedded in them, and let the client work that part out by talking to the service in question (or getting a version number from the caller), then "yes, please."</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 1:47 AM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We're just reworking our endpoint registration on cloud bring up to be<br>
driven by APIs, per the principled separation of concerns I outlined<br>
previously.<br>
<br>
One thing I note is that the keystone intialisation is basically full<br>
of magic constants like<br>
"http://$CONTROLLER_PUBLIC_ADDRESS:8004/v1/%(tenant_id)s"<br>
<br>
Now, I realise that when you have a frontend haproxy etc, the endpoint<br>
changes - but the suffix - v1/%(tenant_id)s in this case - is, AFAICT,<br>
internal neutron/cinder/ etc knowledge, as is the service type<br>
('network' etc).<br>
<br>
Rather than copying those into everyones deploy scripts, I'm wondering<br>
if we could put that into neutronclient etc - either as a query<br>
function (neutron --endpoint-suffix -> 'v1/%(tenant_id)s) or perhaps<br>
something that will register with keystone when told to?<br>
<br>
-Rob<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Converged Cloud<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>
</font></span></blockquote></div><br></div>