Open Stack

+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
>