Open Stack

2015-06-16 5:24 GMT+08:00 Clint Byrum <clint at fewbar.com>:

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

So if our min_version is 2.1 and the max_version is 2.50. That means
alternative implementations need implement all the 50 versions api...that
sounds pain...


>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150616/7d3efd1c/attachment.html>