[openstack-dev] [horizon] feature freeze exception request -- nova simple tenant usages api pagination

Radomir Dopieralski openstack at sheep.art.pl
Tue Jan 24 09:11:01 UTC 2017


No, for some reason Nova will now always limit the number of entries it
sends in a single response, no matter what microversion you use. If you use
microversion of at least 2.40, it will let you request more responses, to
get all the entries. I don't know why they did it like that.

On Tue, Jan 24, 2017 at 9:52 AM, Rob Cresswell (rcresswe) <
rcresswe at cisco.com> wrote:

> As I understand it, if someone configures Nova to use 2.40 via settings,
> then it will use 2.40 for every request. This could likely break Horizon in
> weird ways, which makes it seem risky to try and support it.
>
> What I don’t really understand about this FFE, is why we need to modify
> the behaviour at all; if we keep using an old microversion (I think it
> defaults to 2.1?) then shouldn’t behaviour stay exactly the same?
>
> Rob
>
> > On 23 Jan 2017, at 21:08, Richard Jones <r1chardj0n3s at gmail.com> wrote:
> >
> > [I'm on vacation, so can't look into this too deeply, sorry]
> >
> > I'm not sure I follow Rob's point here. Does the patch
> > https://review.openstack.org/#/c/410337 just check the version to see
> > if it's >= 2.40 and take action appropriately? I don't see how it
> > changes anything to force requesting 2.40 with every request? Then
> > again, I've not been able to look into how the current clients'
> > microversion code is implemented/broken. Is it just that *declaring*
> > the 2.40 version in https://review.openstack.org/#/c/422642 results in
> > all requests being forced to use that version?
> >
> >
> >     Richard
> >
> > On 23 January 2017 at 23:10, Radomir Dopieralski <openstack at sheep.art.pl>
> wrote:
> >> Yes, to do it differently we need to add the microversion support patch
> that
> >> you are working on, and make use of it, or write a patch that has
> equivalent
> >> functionality.
> >>
> >> On Fri, Jan 20, 2017 at 6:57 PM, Rob Cresswell
> >> <robert.cresswell at outlook.com> wrote:
> >>>
> >>> Just a thought: With the way we currently do microversions, wouldnt
> this
> >>> request 2.40 for every request ? There's a pretty good chance that
> would
> >>> break things.
> >>>
> >>> Rob
> >>>
> >>> On 20 January 2017 at 00:02, Richard Jones <r1chardj0n3s at gmail.com>
> wrote:
> >>>>
> >>>> FFE granted for the three patches. We need to support that nova API
> >>>> change.
> >>>>
> >>>> On 20 January 2017 at 01:28, Radomir Dopieralski <
> openstack at sheep.art.pl>
> >>>> wrote:
> >>>>> I would like to request a feature freeze exception for the following
> >>>>> patch:
> >>>>>
> >>>>> https://review.openstack.org/#/c/410337
> >>>>>
> >>>>> This patch adds support for retrieving the simple tenant usages from
> >>>>> Nova in
> >>>>> chunks, and it is necessary for correct data given that related
> patches
> >>>>> have
> >>>>> been already merged in Nova. Without
> >>>>> it, the data received will be truncated.
> >>>>>
> >>>>> In order to actually use that patch, however, it is necessary to set
> >>>>> the
> >>>>> Nova API version to at least
> >>>>> version 3.40. For this, it's necessary to also add this patch:
> >>>>>
> >>>>> https://review.openstack.org/422642
> >>>>>
> >>>>> However, that patch will not work, because of a bug in the
> >>>>> VersionManager,
> >>>>> which for some reason
> >>>>> uses floating point numbers for specifying versions, and thus
> >>>>> understands
> >>>>> 2.40 as 2.4. To fix that, it
> >>>>> is also necessary to merge this patch:
> >>>>>
> >>>>> https://review.openstack.org/#/c/410688
> >>>>>
> >>>>> I would like to request an exception for all those three patches.
> >>>>>
> >>>>> An alternative to this would be to finish and merge the microversion
> >>>>> support, and modify the first patch to make use of it. Then we would
> >>>>> need
> >>>>> exceptions for those two patches.
> >>>>>
> >>>>>
> >>>>> ____________________________________________________________
> ______________
> >>>>> 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
> >>>
> >>>
> >>>
> >>> ____________________________________________________________
> ______________
> >>> 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
> >>
> >
> > ____________________________________________________________
> ______________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170124/4c7c87c3/attachment.html>


More information about the OpenStack-dev mailing list