Hi all! I've been working on moving the ATS config generation from Traffic Ops to a standalone app alongside ORT, that queries the standard TO API to generate its data. I just wanted to put it here, and get some feedback, to make sure the community agrees this is the right direction.
There's a (very) brief spec here: (I might put more detail into it later, let me know if that's important to anyone) https://cwiki.apache.org/confluence/display/TC/Cache-Side+Config+Generation And the Draft PR is here: https://github.com/apache/trafficcontrol/pull/3762 This has a number of advantages: 1. TO is a monolith, this moves a significant amount of logic out of it, into a smaller per-cache app/library that's easier to test, validate, rewrite, deploy, canary, rollback, etc. 2. Deploying cache config changes is much smaller and safer. Instead of having to deploy (and potentially roll back) TO, you can canary deploy on one cache at a time. 3. This makes TC more cache-agnostic. It moves cache config generation logic out of TO, and into an independent app/library. The app (atstccfg) is actually very similar to Grove's config generator (grovetccfg). This makes it easier and more obvious how to write config generators for other proxies. 4. By using the API and putting the generator functions in a library, this really gives a lot more flexibility to put the config gen anywhere you want without too much work. You could easily put it in an HTTP service, or even put it back in TO via a Plugin. That's not something that's really possible with the existing system, generating directly from the database. Right now, I'm just looking for consensus that this is the right approach. Does the community agree this is the right direction? Are there concerns? Would anyone like more details about anything in particular? Thanks,
