Open Stack

On 6/27/2016 9:57 PM, Alex Xu wrote:
> Matt, thanks for the email, I +1 on the next page link. Then user
> needn't build up link by themself.
>
> I also have one more question after review those pagination patches:
>
> As those pagination proposes change the default sort order. So should we
> keep the sort order for old version API?
>     I think it should be yes. For instance-actions, it should keep the
> order sorted by 'create_at' column in old versionAPI. The new version
> API will sort the result by 'updated_at' column.

This sounds reasonable since we were already ordering on created_at for 
instance actions:

https://github.com/openstack/nova/blob/0c5ff5057edcf1f9ab55a559804a5c0c6a8158b2/nova/db/sqlalchemy/api.py#L5976

>     But the question for keypairs and hypervisors, looks like they
> didn't specify the sort order explicitly, so I think they should depend
> on the DB implementation. Should we keep the old version API unspecified
> sort order?

I think Andrew Laski made a comment about this in the keypairs change 
also, that since we never explicitly guaranteed a sort order for these 
before and never documented anything to that effect, enforcing a new 
sort order should not be a problem, regardless of the microversion. The 
natural sort order should be the auto-incrementing id but that's not 
guaranteed. And the hypervisors pagination change is using id for 
sorting. The keypairs change is sorting by name. I think at the summit 
we even told Pavel to push a separate change before the microversion to 
start ordering keypairs since we weren't going to support sort keys.

So I don't have a strong opinion either way. If it's just a difference 
in which DB API method gets called per the microversion, that seems 
simple enough to keep it working as it did before the pagination changes 
are added. If it makes the code much more complicated though, then I'd 
probably not try to retrofit the ordering, or lack thereof.

-- 

Thanks,

Matt Riedemann