Open Stack

Excerpts from Sean Dague's message of 2015-06-15 14:00:43 -0700:
> 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.
> 

Actually that makes an alternative implementation more valuable. Without
microversions those alternative implementations would have to wait a long
time to implement fixes to the API, but now can implement and publish
the fix as soon as the microversion lands. This means that alternative
implementations will lag _less_ behind the primary.