<div dir="ltr">Previously discussed: <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-May/008436.html">http://lists.openstack.org/pipermail/openstack-dev/2013-May/008436.html</a><div><br></div><div style>tl;dr Don't do any of that!</div>
</div><div class="gmail_extra"><br clear="all"><div><div><br></div>-Dolph</div>
<br><br><div class="gmail_quote">On Wed, Jun 19, 2013 at 7:31 PM, Frittoli, Andrea (Cloud Services) <span dir="ltr"><<a href="mailto:frittoli@hp.com" target="_blank">frittoli@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><div><p class="MsoNormal">Hi folks, <u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">While reviewing nova v3 tests, I realized that there is no nova V3 endpoint defined in the catalog in devstack.<u></u><u></u></p>
<p class="MsoNormal">Test have to get the v2 URL, parse it, strip the “v2” string out and replace it with a “v3” one.<u></u><u></u></p><p class="MsoNormal">Because of this I filed <a href="https://bugs.launchpad.net/devstack/+bug/1191798" target="_blank">https://bugs.launchpad.net/devstack/+bug/1191798</a>.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">However working on this I came across two other points: <u></u><u></u></p><p><u></u><span>-<span style="font:7.0pt "Times New Roman"">          </span></span><u></u>There is no support in keystone for having multiple endpoints for different api versions<u></u><u></u></p>
<p><u></u><span>-<span style="font:7.0pt "Times New Roman"">          </span></span><u></u>The following email thread about this topic <a href="http://lists.openstack.org/pipermail/openstack-dev/2013-April/008318.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2013-April/008318.html</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m not very happy with the idea of think having the client mangling the URL to build the right one for the version they need – this would be forcing the restriction of having each API version running behind the same domain name and port, which may not be the case in some deployments.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">IMO keystone is merely exposing the catalogue facility to other services, which are responsible for provisioning the catalog with endpoints, and to maintain those endpoints as well, including multiple versions if needed.<u></u><u></u></p>
<p class="MsoNormal">The solution I proposed for the bug I filed relies on an additional service type called computev3, which can be configured in the clients. However I would prefer to keep the service name to compute, and have the ability of selecting a specific API version from the catalogue.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thoughts? Thanks!<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">andrea<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span>-- <u></u><u></u></span></p><p class="MsoNormal"><span>Andrea Frittoli<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">IaaS Systems Engineering Team<u></u><u></u></span></p><p class="MsoNormal">
<span>HP Cloud Services<u></u><u></u></span></p><p class="MsoNormal"><span>Tel: <a href="tel:%2B44%280%2911731%2062324" value="+441173162324" target="_blank">+44(0)11731 62324</a><u></u><u></u></span></p><p class="MsoNormal">
<u></u> <u></u></p></div></div><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></blockquote></div><br></div>