ocket8888 opened a new pull request, #7099: URL: https://github.com/apache/trafficcontrol/pull/7099
In accordance with the blueprint from #4654, this changes the `active` property of Delivery Services from a simple boolean to a three state system, where the three states are: - ACTIVE - The DS is routed and cache servers will generate configuration for it. The equivalent of `true` today. - PRIMED - The DS is **not** routed, but cache servers will still generate configuration for it. The equivalent of `false` today. - INACTIVE - The DS is not routed **and** cache servers will **not** generate configuration for it. Has no equivalent today. Additionally, because I was making a new DS model already anyway since that's a breaking change, I made some things that are never allowed to be null or undefined into non-reference values (e.g. XMLID is a `string` not a `*string` etc.) and made `lastUpdated` format in RFC3339 in JSON responses. The new model now totally drops `LongDesc1` and `LongDesc2`, which were deprecated in the now-itself-deprecated APIv3 and unavailable for direct use in APIv4 - as an interesting consequence of this and how DSRs are stored internally, **it is no longer possible to make a DSR that will set a DS's `longDesc1` and/or `longDesc2` to anything but `null` _even using APIv3_**. They are shown as `null` in responses, but are otherwise totally ignored by Traffic Ops. DS `longDesc1` and `longDesc2` fields can still be manipulated directly and viewed as normal in APIv3. I also made some changes to the testing utilities, because they weren't registering themselves as helpers so it was difficult to find actual failures. And finally, this PR fixes #7094, which caused me no end of trouble while making this. This PR includes documentation, TO changes, and database migrations, but does not actually make the new state work in `t3c`, nor does it update Traffic Portal with the ability to deal with it. These efforts are left to a later date. <hr/> ## Which Traffic Control components are affected by this PR? - Documentation - Traffic Ops Client (Go) - Traffic Ops ## What is the best way to verify this PR? I've updated the tests, and really there's only one new DS permutation, which has a test case added, so there's not really a whole lot more to do than just run the tests. You can replicate them by using APIv5 to manipulate DSes and DSRs if you like, just make sure everything looks okay. ## If this is a bugfix, which Traffic Control versions contained the bug? - 7.x - 6.x ## PR submission checklist - [x] This PR has tests - [x] This PR has documentation - [x] This PR has a CHANGELOG.md entry - [x] This PR **DOES NOT FIX A SERIOUS SECURITY VULNERABILITY** -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
