Open Stack

On 06/15/2015 04:50 PM, Jim Rollenhagen wrote:
> On Mon, Jun 15, 2015 at 01:07:39PM -0400, Jay Pipes wrote:
>> 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.
> 
> While I tend to agree in principle, do we reasonably expect that other
> implementations of these APIs will implement every one of these
> versions? Can we even reasonably expect another implementation of these
> APIs?
> 
> // jim

Yeh, honestly, I'm not really convinced that thinking we are doing this
for alternative implementations is really the right approach (or even
desireable). Honestly, the transition to microversions makes alternative
implementations harder because there isn't a big frozen API for a long
period of time.

Microversions are about us being honest that the API is going to evolve
with the code, and that we can document and version that evolution very
carefully so that it can be consumed in a deliberate way (and not leave
the consumers randomly guessing). For the same reason we version our
internal RPC payloads and our database versions (which we pair with code).

I'm all for reconsidering what we want to call this header (and yay! we
have a microversioning mechanism by which we could even change that in a
sane way), but I don't think we should rush it, and I definitely don't
think it should be dealt with before we do some more standarization of
the service catalog contents.

	-Sean

-- 
Sean Dague
http://dague.net