On Thu, Feb 5, 2015 at 11:37 AM, Andrey Kurilin <akuri...@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 <akuri...@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 <cbky...@gmail.com> >> wrote: >> >>> >>> >>> On Sat, Jan 31, 2015 at 4:09 AM, Andrey Kurilin <akuri...@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 <cbky...@gmail.com> >>>> wrote: >>>> >>>>> On Fri, 23 Jan 2015 15:51:54 +0200 >>>>> Andrey Kurilin <akuri...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
