[openstack-dev] [python-novaclient][nova] future of --os-compute-api-version option and whole api versioning

Christopher Yeoh cbkyeoh at gmail.com
Fri Feb 6 06:22:13 UTC 2015


On Thu, Feb 5, 2015 at 11:37 AM, Andrey Kurilin <akurilin at mirantis.com>
wrote:

> First results is https://review.openstack.org/#/c/152569/
>
> > - if os-compute-api-version is not supplied don't send any header at all
> > - it is probably worth doing a bit version parsing to see if it makes
> sense eg of format:
> >      r"^([1-9]\d*)\.([1-9]\d*|0)$" or latest
>
> implemented
>
>
> >- handle  HTTPNotAcceptable if the user asked for a version which is not
> supported
> >  (can also get a badrequest if its badly formatted and got through the
> novaclient filter)
> Based on https://review.openstack.org/#/c/150641/ , HTTPNotFound (404)
> will be returned by API, so the current implementation of novaclient is not
> required any changes.
>
>
So a microversion (say v2.12) is a concept which covers the API as a whole,
not just an extension. And as a result there is a concept of a minimum
version supported (currently 2.1) and a maximum). If a client requests a
version which it outside of min<->max they will have a HTTPNotAcceptable
returned.

If a client a requests a version which is valid, but the actual resource
point they attempt to access does not support an implementation (say the
version requested did not support anything yet), they will get a 404 (eg it
pretends not to be there).



> > - show the version header information returned
> Imo, API should return exception with proper message which already include
> this information.
>

Yep, if you request a version which doesn't fit within the global supported
(min<->max) you will get  a 406 which specifies min/max api versions for
that server.

For any other request you get returned an X-OpenStack-Compute-API-Version
header which
specifies the version used - which you may nto have exactly known on the
request if you didn't specify a version (eg not specified or 'latest')

Regards,

Chris


>
> On Mon, Feb 2, 2015 at 2:02 PM, Andrey Kurilin <akurilin at mirantis.com>
> wrote:
>
>> Thanks for the summary, I'll try to send first patch(maybe WIP) in few
>> days.
>>
>> On Mon, Feb 2, 2015 at 1:43 PM, Christopher Yeoh <cbkyeoh at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin <akurilin at mirantis.com>
>>> wrote:
>>>
>>>> Thanks for the answer. Can I help with implementation of novaclient
>>>> part?
>>>>
>>>
>>> Sure! Do you think its something you can get proposed into Gerrit by the
>>> end of the week or very soon after?
>>> Its the sort of timeframe we're looking for to get microversions enabled
>>> asap.... I guess just let me know if it
>>> turns out you don't have the time.
>>>
>>> So I think a short summary of what is needed is:
>>> - if os-compute-api-version is not supplied don't send any header at all
>>> - it is probably worth doing a bit version parsing to see if it makes
>>> sense eg of format:
>>>      r"^([1-9]\d*)\.([1-9]\d*|0)$" or latest
>>> - handle  HTTPNotAcceptable if the user asked for a version which is not
>>> supported
>>>   (can also get a badrequest if its badly formatted and got through the
>>> novaclient filter)
>>> - show the version header information returned
>>>
>>> Regards,
>>>
>>> Chris
>>>
>>>
>>>> On Wed, Jan 28, 2015 at 11:50 AM, Christopher Yeoh <cbkyeoh at gmail.com>
>>>> wrote:
>>>>
>>>>> On Fri, 23 Jan 2015 15:51:54 +0200
>>>>> Andrey Kurilin <akurilin at mirantis.com> wrote:
>>>>>
>>>>> > Hi everyone!
>>>>> > After removing nova V3 API from novaclient[1], implementation of v1.1
>>>>> > client is used for v1.1, v2 and v3 [2].
>>>>> > Since we moving to micro versions, I wonder, do we need such
>>>>> > mechanism of choosing api version(os-compute-api-version) or we can
>>>>> > simply remove it, like in proposed change - [3]?
>>>>> > If we remove it, how micro version should be selected?
>>>>> >
>>>>>
>>>>> So since v3 was never officially released I think we can re-use
>>>>> os-compute-api-version for microversions which will map to the
>>>>> X-OpenStack-Compute-API-Version header. See here for details on what
>>>>> the header will look like. We need to also modify novaclient to handle
>>>>> errors when a version requested is not supported by the server.
>>>>>
>>>>> If the user does not specify a version number then we should not send
>>>>> anything at all. The server will run the default behaviour which for
>>>>> quite a while will just be v2.1 (functionally equivalent to v.2)
>>>>>
>>>>>
>>>>> http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/api-microversions.html
>>>>>
>>>>>
>>>>> >
>>>>> > [1] - https://review.openstack.org/#/c/138694
>>>>> > [2] -
>>>>> >
>>>>> https://github.com/openstack/python-novaclient/blob/master/novaclient/client.py#L763-L769
>>>>> > [3] - https://review.openstack.org/#/c/149006
>>>>> >
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Andrey Kurilin.
>>
>
>
>
> --
> 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/20150206/ea60f47f/attachment.html>


More information about the OpenStack-dev mailing list