Open Stack

2015-06-17 19:46 GMT+08:00 Andrey Kurilin <akurilin at mirantis.com>:

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

If we raise min_versions randomly...that may means we have 50
back-incompatible APIs in the world. So min_version will be raise rarely
for keep back-compatible


>
>
> 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.
>
> __________________________________________________________________________
> 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/20150617/0964c78a/attachment.html>