<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 15, 2015 at 1:24 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.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"><span>On 06/15/2015 01:31 PM, Sean Dague 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">
On 06/15/2015 01:07 PM, Jay Pipes 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">
It has come to my attention in [1] that the microversion spec for Nova<br>
[2] and Ironic [3] have used the project name -- i.e. Nova and Ironic --<br>
instead of the name of the API -- i.e. "OpenStack Compute" and<br>
"OpenStack Bare Metal" -- in the HTTP header that a client passes to<br>
indicate a preference for or knowledge of a particular API microversion.<br>
<br>
The original spec said that the HTTP header should contain the name of<br>
the service type returned by the Keystone service catalog (which is also<br>
the official name of the REST API). I don't understand why the spec was<br>
changed retroactively and why Nova has been changed to return<br>
X-OpenStack-Nova-API-Version instead of X-OpenStack-Compute-API-Version<br>
HTTP headers [4].<br>
<br>
To be blunt, Nova is the *implementation* of the OpenStack Compute API.<br>
Ironic is the *implementation* of the OpenStack BareMetal API.<br>
<br>
The HTTP headers should never have been changed like this, IMHO, and I'm<br>
disappointed that they were. In fact, it looks like a very select group<br>
of individuals pushed through this change [5] with little to no input<br>
from the mailing list or community.<br>
<br>
Since no support for these headers has yet to land in the client<br>
packages, can we please reconsider this?<br>
</blockquote>
<br>
I think you are seeing demons where there are none.<br>
</blockquote>
<br></span>
I don't think there are any demons anywhere :) Just a lack of communication and/or consensus.<span><br>
<br>
> I don't think it was<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">
ever really clear in the specification that official project short<br>
moniker was critical to the spec vs. code name that everyone uses. While<br>
I didn't weigh in on the review in question, I wouldn't have really seen<br>
an issue with it at the time.<br>
</blockquote>
<br></span>
OK.<span><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">
Honestly, we should work through standardization of the service catalog<br>
(as was discussed at Summit) first and before we push out a microversion<br>
on these projects to change this header, especially as that is the hook<br>
by which projects are versioning on now.<br>
</blockquote>
<br></span>
Sure, good point. Morgan, Adam, where are we on that?<span><font color="#888888"><br><br></font></span></blockquote><div><br></div><div>So we have a x-project-spec with some initial comments [1] from Anne. Generally speaking I think we've pushed the definition of what goes into the SC (not a restructure of the catalog as that is API contract impacting) to the API-WorkingGroup with TC oversight for specific "type"s and their definitions [2]. </div><div><br></div><div>So in short: </div><div>1) Keystone can't enforce the types (because some types wont be listed)</div><div><br></div><div>2) Devstack should be updated to conform to the API-WG / TC oversight of the "best practices" (aka, nova is "compute", etc)</div><div><br></div><div>3) Any urls (aka VersionList? PublicURL? etc) that we want to make default can be added as long as we maintain the current ones.</div><div><br></div><div>4) "Name" for endpoints will be deprecated (but cannot be removed because of API contract.</div><div><br></div><div>5) Keystone will implement a JSON schema to make sure everything does conform but allow for "Extra" values while we are in the transition period (for required/changed values). A future catalog type (if it exists) will see some restructure.</div><div><br></div><div>I think the long-term enforcement of type (etc) will fall to Defcore, but that is after we've made these changes via API-WG and TC.</div><div><br></div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/181393/">https://review.openstack.org/#/c/181393/</a></div></div>[2] <a href="https://etherpad.openstack.org/p/service-catalog-cross-project-vancouver">https://etherpad.openstack.org/p/service-catalog-cross-project-vancouver</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">Sent via mobile</div></div>