It was done like that to circumvent the existing possibility DoS-like usage requests when there are thousands of instances.
Some of the history behind that decision can be found in the spec discussions [1]. And an easier to read spec can be found here [2]. [1] https://review.openstack.org/#/c/386771/ [2] https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/paginate-simple-tenant-usage.html --diana On Tue, Jan 24, 2017 at 4:11 AM, Radomir Dopieralski <openst...@sheep.art.pl> wrote: > 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) > <rcres...@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 <r1chardj0...@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 >> > <openst...@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.cressw...@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 <r1chardj0...@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 >> >>>> <openst...@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-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 >> >>> >> >>> >> >>> >> >>> >> >>> __________________________________________________________________________ >> >>> 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 >> >> >> > >> > >> > __________________________________________________________________________ >> > 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 > > > > __________________________________________________________________________ > 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
