Open Stack

2016-05-20 20:05 GMT+08:00 Sean Dague <sean at dague.net>:

> 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"
>
>
Are you looking for code sharing or one microversion? For code sharing, it
sounds ok if people have some co-work. Probably we need a common pagination
supported model_query function for all of those. For one microversion, i'm
a little hesitate, we should keep one small change, or enable all in one
microversion. But if we have some base code for pagination support, we
probably can make the pagination as default thing support for all list
method?


> 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
>
> __________________________________________________________________________
> 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/20160530/a3058f69/attachment.html>