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

Radomir Dopieralski openstack at sheep.art.pl
Wed Jan 25 08:53:55 UTC 2017


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.clarke at 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
> <openstack at 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)
> > <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
> >
> >
> >
> > ____________________________________________________________
> ______________
> > 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/20170125/275f4757/attachment.html>


More information about the OpenStack-dev mailing list