updated /deliveryservices/{{ID}}/servers and /deliveryservices/{{ID}}…#4676
updated /deliveryservices/{{ID}}/servers and /deliveryservices/{{ID}}…#4676ocket8888 merged 9 commits intoapache:masterfrom
Conversation
d86d9cb to
9a87861
Compare
There was a problem hiding this comment.
This should actually be "null means 'no limit'" - that's one thing that's changed since the blueprint was merged
There was a problem hiding this comment.
Same as above RE null vs 0
There was a problem hiding this comment.
nit: GoDocs should end with a period.
There was a problem hiding this comment.
nit: GoDocs should consist of complete sentences with proper capitalization and terminated by periods.
There was a problem hiding this comment.
Same as above RE: complete sentences
There was a problem hiding this comment.
Same as above RE: period.
There was a problem hiding this comment.
Why not make DSServer point to the current definition of a Delivery Service Server? Coupling to the API version means that things stop making sense unless we update that every time the API version changes; like if we have DSServerV30 then APIv3.1 comes out and no changes are made to the structure, we're either using a confusingly version structure, or we have to remember to do something like type DSServer31 = DSServer30 and then do a find/replace to update things.
1dd3e4e to
be9a322
Compare
be9a322 to
03f1caa
Compare
…/servers/eligible to use multiple interfaces
ef84e3b to
0e7b22f
Compare
ocket8888
left a comment
There was a problem hiding this comment.
All unit and api/client integration tests passing, manually verified old-format output in api v1/v2 and new-format output in v3
| s.ip_gateway, | ||
| s.ip_netmask, | ||
| ARRAY ( | ||
| SELECT ( json_build_object ( |
There was a problem hiding this comment.
So this does worry me a bit still. When reviewing @ocket8888's PR I found that this query using json_build_object is like 12x slower than querying the interfaces and IPs separately (without using json_build_object) and manually populating the servers structs with that data. Also, we should really be making the same query here as we would in the /servers API. It seems like we could make this better by sharing that code/query here.
Locally (which I typically assume performs much better than in Prod), for a DS w/ ~1000 servers assigned, this API takes 850ms for me, whereas before this PR, it takes ~75ms.
There was a problem hiding this comment.
True enough. This is also still how /servers/details is being done.
…/servers/eligible to use multiple interfaces
What does this PR (Pull Request) do?
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
If this is a bug fix, what versions of Traffic Control are affected?
The following criteria are ALL met by this PR
Additional Information