[openstack-dev] [api][nova][ironic] Microversion API HTTP header
akurilin at mirantis.com
Wed Jun 17 11:46:57 UTC 2015
Why does alternative implementation need to implement all 50 versions?
As far as I understand, API side should not support all versions, that is
why version info returns min and max versions
On Tue, Jun 16, 2015 at 11:36 AM, Alex Xu <soulxu at gmail.com> wrote:
> 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  that the microversion spec for
>> Nova 
>> > >> and Ironic  have used the project name -- i.e. Nova and Ironic --
>> > >> of the name of the API -- i.e. "OpenStack Compute" and "OpenStack
>> > >> Metal" -- in the HTTP header that a client passes to indicate a
>> > >> 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
>> > >> official name of the REST API). I don't understand why the spec was
>> > >> retroactively and why Nova has been changed to return
>> > >> X-OpenStack-Nova-API-Version instead of
>> X-OpenStack-Compute-API-Version HTTP
>> > >> headers .
>> > >>
>> > >> To be blunt, Nova is the *implementation* of the OpenStack Compute
>> > >> 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
>> > > 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)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev