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