<div dir="ltr"><div class="gmail_extra">Yes, it's a change in default client-side behavior (the client can explicitly request ?nocatalog). The default server-side behavior is to continue returning catalogs in requests unless the client requests otherwise. Before the client adopts the new default, we need well-established support in auth_token for fetching catalogs when a service expects one, but auth_token finds it to be missing from PKI tokens.</div>


<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 31, 2014 at 6:59 AM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>On 07/30/2014 10:57 AM, Dolph Mathews wrote:<br>
> We recently merged an implementation for GET /v3/catalog which finally<br>
> enables POST /v3/auth/tokens?nocatalog to be a reasonable default<br>
> behavior, at the cost of an extra HTTP call from remote service back to<br>
> keystone where necessary.<br>
<br>
</div>Is that really a safe default change to make?  It looks like v3 has<br>
already been marked as stable, and this would be a non<br>
backwards-compatible change to the API.<br>
<span><font color="#888888"><br>
--<br>
Russell Bryant<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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></div>