Open Stack

On 06/16/2015 04:12 AM, Ken'ichi Ohmichi wrote:
> 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.

I apologize for making you feel bad about it, that wasn't my intent, 
Ken'ichi. :(

> 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.

Well, I actually like Kevin's suggestion of just removing the 
project/service-type altogether and using OpenStack-API-Version, but to 
answer your question above, I'd just say that having a single API for 
"OpenStack Containers" has value. See my previous responses about why 
having the API mean a single thing allows developers to better use our APIs.

>> 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.

Understood.

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

Good point,
-jay