Open Stack

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

-- 
Sean Dague
http://dague.net