Open Stack

On 01/05/2015 10:13 AM, Steven Kaufer wrote:
> The nova, cinder, and glance REST APIs support listing instances,
> volumes, and images in a specific order.  In general, the REST API
> supports something like:
>
>    ?sort_key=key1&sort_dir=asc&sort_key=key2&sort_dir=desc
>
> This sorts the results using 'key1' as the primary key (in ascending
> order), 'key2' as the secondary key (in descending order), etc.
>
> Note that this behavior is not consistent across the projects.  Nova
> supports multiple sort keys and multiple sort directions, glance
> supports multiple sort keys but a single direction, and cinder only
> supports a single sort key and a single sort direction (approved kilo BP
> to support multiple sort keys and directions is here:
> https://blueprints.launchpad.net/cinder/+spec/cinder-pagination).
>
> The purpose of this thread is to discuss how the sort information should
> be inputted to the client.
>
> In nova, (committed in kilo https://review.openstack.org/#/c/117591/)
> the syntax is:  --sort key1:asc,key2:desc
> In cinder, the syntax is:  --sort_key key1 --sort_dir desc
> In glance, the proposed syntax (from
> https://review.openstack.org/#/c/120777/) is: --sort-key key1 --sort-key
> key2 --sort-dir desc
>
> Note that the keys are different for cinder and glance (--sort_key vs.
> --sort-key).  Also, client side sorting does not actually work in cinder
> (fix under review at https://review.openstack.org/#/c/141964/).
>
> Giving that each of these 3 clients will be supporting client-side
> sorting in kilo, it seems that we should get this implemented in a
> consistent manner.  It seems that the 2 options are either:
>
>    --sort-key key1 --sort-dir desc --sort-key key2 --sort-dir asc
>    --sort key1:asc,key2:desc
>
> Personally, I favor option 2 but IMO it is more important that these are
> made consistent.
>
> Thoughts on getting consistency across all 3 projects (and possibly others)?

Yeah, I personally like the second option as well, but agree that 
consistency is the key (pun intended) here.

I would say let's make a decision on the standard to go with (possibly 
via the API or SDK working groups?) and then move forward with support 
for that option in all three clients (and continue to support the old 
behaviour for 2 release cycles, with deprecation markings as appropriate).

Best,
-jay