<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 26, 2013 at 2:47 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On 25/11/13 16:50 -0600, Dolph Mathews wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On Mon, Nov 25, 2013 at 2:41 AM, Flavio Percoco <<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>> wrote:<br>
<br>
On 25/11/13 09:28 +1000, Jamie Lennox wrote:<br>
<br>
So the way we have this in keystone at least is that querying GET /<br>
will<br>
return all available API versions and querying /v2.0 for example is a<br>
similar result with just the v2 endpoint. So you can hard pin a version<br>
by using the versioned URL.<br>
<br>
I spoke to somebody the other day about the discovery process in<br>
services. The long term goal should be that the service catalog<br>
contains<br>
unversioned endpoints and that all clients should do discovery. For<br>
keystone the review has been underway for a while now:<br>
<a href="https://review.openstack.org/#/c/38414/" target="_blank">https://review.openstack.org/#<u></u>/c/38414/</a> the basics of this should be<br>
able to be moved into OSLO for other projects if required.<br>
<br>
<br>
Did you guys create your own 'home document' language? or did you base<br>
it on some existing format? Is it documented somewhere? IIRC, there's<br>
a thread where part of this was discussed, it was related to horizon.<br>
<br>
I'm curious to know what you guys did and if you knew about<br>
JSON-Home[0] when you started working on this.<br>
<br>
<br>
It looks like our multiple choice response might predate Nottingham's proposal,<br>
but not by much. In keystone, it's been stable since I joined the project,<br>
midway through the diablo cycle (summer 2011). I don't know any more history<br>
than that, but I've CC'd Jorge Williams, who probably knows.<br>
<br>
I really like Nottingham's approach of adding relational links from the base<br>
endpoint, I've been thinking about doing the same for keystone for quite a<br>
while.<br>
</blockquote>
<br></div></div>
As crazy as it sounds, have you guys considered migrating to<br>
Nottingham's approach?<br>
<br></blockquote><div><br></div><div>It only sounds crazy because I have no idea how to "migrate" an unversioned endpoint :) Skimming through his proposal, it looks like it might actually be compatible with ours to include side by side? If so, we could support both for a couple releases before moving on.</div>
<div><br></div><div>Does this proposal have much traction outside the OpenStack community? (and how much traction does it have within the community already?)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
We picked this approach because we didn't want to invent it ourselves<br>
and this happens to have a well defined RFC as well.<br>
<br>
If there's something Nottingham's proposal lacks of, I think we could<br>
provide some feedback and help making it better.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
We used json-home for Marconi v1 and we'd want the client to work in a<br>
'follow your nose' way. Since, I'd prefer OpenStack modules to use the<br>
same language for this, I'm curious to know why - if so - you<br>
created your own spec, what are the benefits and if it's documented<br>
somewhere.<br>
<br>
<br>
Then why didn't Marconi follow the lead of one of the other projects? ;)<br>
</blockquote>
<br></div>
LOOOL, I knew you were going to say that. I think I knew about you<br>
guys having something similar but at some point I most have forgotten<br>
about it. That being said, the main rationals were:<br>
<br>
1) Using something documented and known upstream made more sense<br>
and it also helps getting more contributions from the community.<br>
2) We already knew it, which falls back in point 1.<div class="im"><br></div></blockquote><div><br></div><div>Hey, you set yourself up! Seriously though, I welcome the innovation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I completely agree though - standardized version discovery across the ecosystem<br>
would be fantastic.<br>
</blockquote>
<br></div>
All that being said, I don't think it would be very hard to migrate<br>
Marconi to something common if we agree that json-home is not good<br>
enough for OpenStack. Nonetheless, it'd be a shame not to provide<br>
feedback to Mark Nottingham about it. So far, his approach has been<br>
good enough for us - but, you know, Marconi is still way too small.<br>
<br>
Is keystone's home schema spec documented somewhere?<br></blockquote><div><br></div><div>It's actually documented as part of the v2.0 API for keystone, although I really believe it should be it's own API specification (e.g. Nottingham's approach):</div>
<div><br></div><div><a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v2.0/src/docbkx/wadl/identity-admin.wadl#L185">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v2.0/src/docbkx/wadl/identity-admin.wadl#L185</a><br>
</div><div><br></div><div><a href="https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v2.0/src/docbkx/xsd/version.xsd#L35">https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v2.0/src/docbkx/xsd/version.xsd#L35</a><br>
</div><div><br></div><div>We use the same basic structure to serve the multiple choice response and versioned endpoints:</div><div><br></div><div> GET /</div><div> GET /v2.0/</div><div> GET /v3/</div><div><br></div><div>
However, the multiple choice response contains the details for both versions.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Cheers,<br>
FF<span class=""><font color="#888888"><br>
<br>
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><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><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>