+0, only because I personally don't have to check configs using the ATS config APIs very often but am generally in favor of deleting cruft out of the API.
My main concern is that people depend on the ATS config APIs somewhat in order to see what config would actually be generated for a given cache in TO (notwithstanding things like __RETURN__ or the anymap override stuff that ORT processes before laying down the configs). That's pretty handy, so IMO we'd need something equally as handy for anyone to use to check a config file for a given cache without having to ssh into the cache itself. While not quite as handy as the ATS config API endpoints, I _think_ the `atstccfg` executable could get pretty close, but it could probably use a good README to explain how to use it as a standalone tool. Then operators could clone the repo locally, build it, configure it, and use it from the CLI to view config files for a given server. This might also mean making it easier in general to use as a standalone CLI application. - Rawlin On Mon, Nov 4, 2019 at 3:24 PM Robert Butts <[email protected]> wrote: > > I'd like to propose we deprecate & remove the Traffic Ops ATS Cache Config > endpoints. In fact, I'd like to propose we Deprecate in Master now, and in > the following Major Release (5.0) that we remove the code and change the > endpoints to return a 501 Not Implemented. > > This follows the TC SemVer versioning deprecate schedule (giving users 2 > major versions to upgrade ORT before the endpoints older ORT uses are > removed); but does _not_ follow the API SemVer Version Promise and > deprecate schedule. > > This is mostly breaking the Semantic Versioning API Promise. The endpoints > would still exist, but they wouldn't be usable anymore. Normally, I'm the > last person to ever want to break SemVer. But in this particular case, I > think it's more dangerous not to. > > Because the Cache Configs have been moved to the client-side generator run > by ORT, these endpoints are no longer used. I had hoped to move most of the > code to a library, and I did move all the logic there. But unfortunately, > what I found when I actually wrote the generator, was that a great deal of > the code is loading data, not logic. The > `traffic_ops/traffic_ops_golang/ats` directory has 5,300 lines of code. > > That's 5k lines which won't be well-maintained, because nobody will be > using it, everyone will be using the ORT with the client-side generator. > > These endpoints also aren't regular user endpoints; generally speaking, > nobody should be using them anymore, TC users should be using ORT which > calls atstccfg. If someone does want to generate their own configs, you > should use the lib/go-atscfg library calling regular data endpoints, not > the TO config endpoints which aren't used or maintained. If someone really, > really wants TO to still generate the endpoints (along with a > different/modified ORT config deployment), you can still write a TO plugin > to use lib/go-atscfg to create and serve configs. > > In summary, I don't take breaking users lightly, but I think the danger of > keeping the unused ATS configs outweighs breaking SemVer here. > > Thoughts?
