<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-06-15 19:50 GMT+02:00 Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Jay Pipes's message of 2015-06-15 10:07:39 -0700:<br>
<span class="">> 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>
<br>
</span>I tend to agree with you.<br>
<br>
The juxtaposition is somewhat surprising. [1] Is cited as the reason for<br>
making the change, but that governance change is addressing the way we<br>
govern projects, not API's. The goal of the change itself is to encourage<br>
competition amongst projects. However, publishing an OpenStack API with<br>
a project name anywhere in it is the opposite: it discourages alternative<br>
implementations. If we really believe there are no sacred cows and a nova<br>
replacement (or proxy, or accelerator, or or or..) could happen inside the<br>
OpenStack community, then we should be more careful about defining the API<br></blockquote><div><br></div><div>If Ironic will still be the main authority to define "the baremetal API", header renaming won't help the alternative implementations.<br><br></div><div>Also, what to use for services, that do not have direct program mapping? I.e., I'm planning to add microversioning to ironic-inspector. Who is going to define a proper service name? Myself? The ironic team? Should I bother the TC?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
However, if we do believe that Nova and Ironic are special, then the API<br>
can stand as-is, though I still find it sub-optimal.<br>
<br>
I'm a little bit worried that we don't have a guiding principle to point<br>
at somewhere. Perhaps the API WG can encode guidance either way ("We use<br>
project names", or "we use service types").<br>
<br>
[1] <a href="https://review.openstack.org/#/c/145740/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/145740/</a><br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks,<br>
> -jay<br>
><br>
> [1] <a href="https://review.openstack.org/#/c/187112/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/187112/</a><br>
> [2]<br>
> <a href="https://github.com/openstack/nova-specs/blob/master/specs/kilo/implemented/api-microversions.rst" rel="noreferrer" target="_blank">https://github.com/openstack/nova-specs/blob/master/specs/kilo/implemented/api-microversions.rst</a><br>
> [3]<br>
> <a href="https://github.com/openstack/ironic-specs/blob/master/specs/kilo/api-microversions.rst" rel="noreferrer" target="_blank">https://github.com/openstack/ironic-specs/blob/master/specs/kilo/api-microversions.rst</a><br>
> [4] <a href="https://review.openstack.org/#/c/155611/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/155611/</a><br>
> [5] <a href="https://review.openstack.org/#/c/153183/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/153183/</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>--<br></div>-- Dmitry Tantsur<br><div>--<br></div></div></div>
</div></div>