I prepared a patch that forces the use of 2.40 api version if it's available for that particular endpoint. Instead of waiting for the microversion patch, I simply copied the needed fragments from it -- we can fix that later once we have proper microversion support implemented.
https://review.openstack.org/#/c/424585/ On Tue, Jan 24, 2017 at 4:08 PM, Diana Clarke <diana.joan.cla...@gmail.com> wrote: > 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 >
__________________________________________________________________________ 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