Open Stack

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
https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L25-L26

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 [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
>>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Best regards,
Andrey Kurilin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150617/e2d251a1/attachment.html>