Bug 2017542

Summary: Designate DNS – tsigkeys, default sort key for ordering is “created_at” instead of the “ID”
Product: Red Hat OpenStack Reporter: Arkady Shtempler <ashtempl>
Component: openstack-designateAssignee: Don Kehn <dkehn>
Status: CLOSED UPSTREAM QA Contact: Toni Freger <tfreger>
Severity: medium Docs Contact:
Priority: medium    
Version: 17.0 (Wallaby)CC: dkehn, michjohn, njohnston, scohen
Target Milestone: gaKeywords: Triaged
Target Release: ---Flags: ifrangs: needinfo? (dkehn)
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-21 20:38:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Arkady Shtempler 2021-10-26 18:58:34 UTC 
According the Doc: https://docs.openstack.org/ ID is a default key:

Sorts the response by the this attribute value. Default is id. You can specify multiple pairs of sort key and sort direction query parameters. If you omit the sort direction in a pair, the API uses the natural sorting direction of the server attribute that is provided as the sort_key.

Actually the default key used in code is “created_at”
https://github.com/openstack/designate/blob/master/designate/sqlalchemy/base.py#L225
Comment 3 Don Kehn 2022-05-10 18:06:25 UTC 
So after spending some time on the sort_key and its current default of 'created_at' versus documentation indicating 'id', here's what I think. Typically in database design the id is detained by an autoincrement-er unsigned int type value, there are a ton of reasons why this is done this way. Openstack used an UUID for the primary key, which is not wrong, but from a purely DB view it is not optimum, which is a long story. By using the UUID and ensuring its uniqueness each time a row is inserted into a table with this as the primary key there is no guarantee of the sort order. whereas an id of an auto-increment nature sort order is guaranteed by insert order. So changing the  default sort_key or id from created_at causes a lot of tests to fail when trying to match against a sorted list, for example. In nove they default generally to 'created_at', because it guarantees the insert order. 

In Designate there is one place in the Doc, api-ref where the sort_key is mentioned, which is an easy change, whereas a code change is going to be messy, because it exposes a lot of test assumptions made on the ordering. IMHO, the insert order is critical versus the unknown predictability of the randomness of the UUID. Will meet with the author of this bug and PTL.
Comment 4 Don Kehn 2022-05-11 16:05:01 UTC 
After conversations with QE we will be changing the api-ref documentation.
Comment 7 Michael Johnson 2022-06-21 20:38:25 UTC 
Closing this with "upstream" as the proposed fix is in the API reference which is an upstream only document.