<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Apr 30, 2013 at 8:09 PM, Gabriel Hurley <span dir="ltr"><<a href="mailto:Gabriel.Hurley@nebula.com" target="_blank">Gabriel.Hurley@nebula.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-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m on board with almost all those points.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">1: check, should be the default, and what we do in devstack.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">2: check.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">3: check, though I think you should have to pass in something explicit to say “use this endpoint as is.” I don’t want to be guessing at “does this URL contain
a version?”</span></p></div></div></blockquote><div><br></div><div style>Rather than guessing, I think the client should GET whatever endpoint it's given, and figure out what's there (is it the root of the service? is it a versioned endpoint? do I even understand the response?)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">4: check.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">5: check.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">6: (about project ids in urls) The argument in favor of them (passed to me by some of the original Nova devs) is that by the strictest definition, to be RESTful
an API can’t change its URL structure based on context, so any context which can alter the response has to go in the URL.</span></p></div></div></blockquote><div><br></div><div style>Agree.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Personally I think this is an impractical requirement and most modern RESTful APIs have completely thrown out this notion. I’m 100% in
favor of eliminating the practice in OpenStack, but it would require a significant deprecation process.</span></p></div></div></blockquote><div><br></div><div style>For the sake of getting expected behavior out of intermediate caching, I think it's a practical requirement.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">In the meantime I think the clients should know if a project ID belongs in the URL and should be capable of constructing those URLs themselves from the
root service endpoint contained in the catalog.</span></p></div></div></blockquote><div><br></div><div style>Big +1, it should be a client-side issue.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’ll have a formal proposal for all this in the next couple days,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p style="margin-left:29.25pt">
<u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>-<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Gabriel<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Dolph Mathews [mailto:<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>]
<br>
<b>Sent:</b> Tuesday, April 30, 2013 3:27 PM<br>
<b>To:</b> OpenStack Development Mailing List<br>
<b>Subject:</b> Re: [openstack-dev] Keystone Service Catalog endpoints vs. API versions<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">Some constraints to solving this problem that I've had on my mind... given that we need to continue to support *versioned* endpoints being provided by the catalog, clients should:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">1) be configurable with an unversioned URL, and automatically work with the client's preferred API version (preferred being highest client-server compatible API, using 'stable' endpoints before anything else).<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">2) be configurable with an unversioned URL and a major version specifier (e.g. client.Client(..., version=3), and forcibly work with that API version (e.g. /v3/ or /v3.1/ or whatever) if it's available<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">3) be configurable with a versioned URL, and forcibly use the API available at that endpoint<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">4) if the best match is not marked as "stable", then the client should raise a warning to the user<u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">5) if the only match is not available (e.g. very old client vs very new service), then the client should abort gracefully<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The above completely ignores the issue of tenant/project-specific endpoints, which is a concept I'm not a huge fan of, as it seems like context that auth_token middleware should be able to sufficiently provide... so, there's surely some
issue there I'm not considering.<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><br clear="all">
<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-Dolph<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Apr 26, 2013 at 9:58 PM, Dolph Mathews <<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>> wrote:<u></u><u></u></p>
<div>
<p class="MsoNormal">+1; ideally the service catalog should not contain any versioned endpoints.<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="color:#888888"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span style="color:#888888">-Dolph<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Fri, Apr 26, 2013 at 5:05 PM, Brian Waldon <<a href="mailto:bcwaldon@gmail.com" target="_blank">bcwaldon@gmail.com</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">Keystone should not have any versions in its service catalog endpoints as version publication and negotiation belongs to the service itself. Your third option is the solution to the core problem here. And to be clear, in addition to the
host/port, the endpoints should also be able to define a base path.<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
On Apr 26, 2013, at 2:20 PM, Gabriel Hurley wrote:<br>
<br>
> I've been working on API version selection in Horizon and came to an odd realization:<br>
><br>
> Keystone's service catalog can (and in the case of devstack currently does) send out an endpoint for a version which is not the latest stable API. In this case we have the Keystone v3 API, but devstack sets the Keystone SC entry to v2.<br>
><br>
> This leaves me with three options:<br>
><br>
> 1. Treat the Service Catalog's version choice as the "preferred" API version and just go with it.<br>
> 2. Treat the Service Catalog as a "suggested" version but query the root of the API to see if there's a different version which Horizon would prefer.<br>
> 3. Rewrite/redefine the service catalog so that it only returns the hosts/ports for the services. This would require a lot of reworking in the clients, too.<br>
><br>
> I'm interested in input from the community; option 1 is the easiest, option 2 solves the problem for me, and option 3 is superior insofar as allowing flexible version choosing based on the what the consumer is able to handle but requires the most work.<br>
><br>
> Thoughts?<br>
><br>
> - Gabriel<br>
><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>
<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><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</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></div>