[openstack-dev] [api][nova][ironic] Microversion API HTTP header

Ken'ichi Ohmichi ken1ohmichi at gmail.com
Tue Jun 16 08:12:38 UTC 2015

2015-06-16 2:07 GMT+09:00 Jay Pipes <jaypipes at gmail.com>:
> It has come to my attention in [1] that the microversion spec for Nova [2]
> and Ironic [3] have used the project name -- i.e. Nova and Ironic -- instead
> of the name of the API -- i.e. "OpenStack Compute" and "OpenStack Bare
> Metal" -- in the HTTP header that a client passes to indicate a preference
> for or knowledge of a particular API microversion.
> The original spec said that the HTTP header should contain the name of the
> service type returned by the Keystone service catalog (which is also the
> official name of the REST API). I don't understand why the spec was changed
> retroactively and why Nova has been changed to return
> X-OpenStack-Nova-API-Version instead of X-OpenStack-Compute-API-Version HTTP
> headers [4].
> To be blunt, Nova is the *implementation* of the OpenStack Compute API.
> Ironic is the *implementation* of the OpenStack BareMetal API.
> The HTTP headers should never have been changed like this, IMHO, and I'm
> disappointed that they were. In fact, it looks like a very select group of
> individuals pushed through this change [5] with little to no input from the
> mailing list or community.

Yeah, that is my regret now. Sorry about that.
It was better to take conversation more on ml or some place.

but I have the same question with Dmitry.
If using service names in the header, how to define these name before that?
Current big-tent situation can make duplications between projects like
X-OpenStack-Container-API-Version or something.
Project names are unique even if they are just implementations.

> Since no support for these headers has yet to land in the client packages,
> can we please reconsider this?

IMO, I am fine to change them if we build a consensus about that.
My main concern is just consistency between projects.

In addition, Tempest also doesn't support/test microversions at all yet.
So it seems good timing to reconsider it now.

Ken Ohmichi

More information about the OpenStack-dev mailing list