ocket8888 commented on PR #7099: URL: https://github.com/apache/trafficcontrol/pull/7099#issuecomment-1304011270
It looks like I accidentally removed `regional` from the docs when I rebased them after it was added, so I'll fix that and the migration timestamps. Other than that: > 4. Could create DS and DSR with longDesc1 and longDesc2 in the JSON payload with all 3 API versions. Per the description in the PR, I shouldn't be able to do so. I think maybe I should clarify. You should be able to create a DS and DSR with any extra fields specified that you want. You could set `"foo": "bar"` and it shouldn't break anything. But it just shouldn't be stored. The same thing should happen with `longDesc1` and `longDesc2` in APIv5. Requests containing those should succeed, but no matter what you set them to, they should be `null` when you GET it in APIv3. Also, because DSRs are always stored at the latest API version, you should be able to create a DSR that sets a DS's `longDesc1`/`longDesc2` to anything you want, but even if you do that in APIv3 it should be null when you GET it afterward. Also, the legacy structures for DSes use the `omitempty` directive in the `json` portion of their struct tags for those fields, so when `longDesc1`/`longDesc2` is/are `NULL` in the database, it/they are omitted from the response, so in that case it looks the same as if I had removed them from that version too (but I didn't I swear). Basically those will always be missing from DSRs in APIv3 but that's the same as if you used that version to set them explicitly to null before these changes. That said, it looks like DSRs are always showing APIv5 representations in responses to POST requests on this branch - which doesn't fail tests because I guess the APIv3 client doesn't decode/return the `response` to those requests. Which I can't add because it'd be a breaking change, so I'll just need to fix and test manually, since a test for that can't really be written easily. > 5. [Routing Name can be changed to default #7094](https://github.com/apache/trafficcontrol/issues/7094) didn't seem like it was fixed. I am able to change the routingName even when the value is set to cdn That issue doesn't really exist. I think when I checked for it on master I forgot to generate SSL Keys for the delivery service first. I'll close that. > 11. `/users/{{ID}}/deliveryservices` cannot curl this API with any versions This endpoint existed in API versions 1 and 2, which existed when that blueprint was written but no longer do. So it's fine to be unreachable, since it would've been before anyway. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@trafficcontrol.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
