Open Stack

On Tue, Jun 28, 2016, at 02:09 PM, Matt Riedemann wrote:
> 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.

I think the most important thing is some sort of generally stable
ordering so two requests with no intervening change return the same
ordering. But I also don't view it as a contract that we have to ensure
through a change, either a microversion or a data migration. If we're
stable before the change and stable afterwards then some temporary
instability should be okay as long as we return the correct data.

If users need a completely predictable sort order then we need to offer
a sort_key parameter. Though I'm not suggesting we do that.

> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> 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