Thanks for the information, really hope these two can get merged for Newton: https://review.openstack.org/#/c/240401/ https://review.openstack.org/#/c/239869/
On Sat, May 21, 2016 at 5:55 AM, Jay Pipes <[email protected]> wrote: > +1 on all your suggestions below, Sean. > > -jay > > > On 05/20/2016 08:05 AM, Sean Dague wrote: > >> There are a number of changes up for spec reviews that add parameters to >> LIST interfaces in Newton: >> >> * keypairs-pagination (MERGED) - >> >> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2 >> * os-instances-actions - https://review.openstack.org/#/c/240401/ >> * hypervisors - https://review.openstack.org/#/c/240401/ >> * os-migrations - https://review.openstack.org/#/c/239869/ >> >> I think that limit / marker is always a legit thing to add, and I almost >> wish we just had a single spec which is "add limit / marker to the >> following APIs in Newton" >> >> Most of these came in with sort_keys as well. We currently don't have >> schema enforcement on sort_keys, so I don't think we should add any more >> instances of it until we scrub it. Right now sort_keys is mostly a way >> to generate a lot of database load because users can sort by things not >> indexed in your DB. We really should close that issue in the future, but >> I don't think we should make it any worse. I have -1s on >> os-instance-actions and hypervisors for that reason. >> >> os-instances-actions and os-migrations are time based, so they are >> proposing a changes-since. That seems logical and fine. Date seems like >> the natural sort order for those anyway, so it's "almost" limit/marker, >> except from end not the beginning. I think that in general changes-since >> on any resource which is time based should be fine, as long as that >> resource is going to natural sort by the time field in question. >> >> So... I almost feel like this should just be soft policy at this point: >> >> limit / marker - always ok >> sort_* - no more until we have a way to scrub sort (and we fix weird >> sort key issues we have) >> changes-since - ok on any resource that will natural sort with the >> updated time >> >> >> That should make proposing these kinds of additions easier for folks, >> >> -Sean >> >> > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
