1. The current names are daemon-specific, and are tricky to rename ('ats-tls' is currently the name for an haproxy-based service).
2. We historically had separate conftool keys for the varnish-fe cache (for port 80) and the tls terminator (port 443) so they could be depooled independently as they were technically run by two separate daemons.
   • However, using them independently only works in one direction: you could in theory depool and stop haproxy's port 443 service while varnish-fe continues serving port 80
   • Going the other way - any need to depool/stop varnish-fe requires depooling the haproxy tls termination, as it depends on varnish-fe implicitly to handle any real requests.
   • Given port 443 is the far more important of the two in the modern era, it's at best confusing to allow them to be separately depooled this way.
3. The current forward-looking plan is to move port 80 up to haproxy anyways ( T323557 ), as the function of port 80 for the cache clusters is very deterministic (redirect or deny), and haproxy is far more efficient and resilient at such a task (and at handling high connection volume in general, as it doesn't have a thread-per-client-conn scaling model like varnish). When this happens, we'd want both keys to be in sync in all cases anyways (as then you couldn't operate on the other daemon without affecting both ports' traffic).

For all of these reasons: we should replace the 'varnish-fe' and 'ats-tls' keys with a singular 'cdn' key and transition pybal and various supporting scripts to the new scheme.

The 'ats-be' key will still exist independently for now, as it continues to serve an independent purpose for now (for the chashing between cache nodes for the backend). There's some related work to build on this later though, as 'ats-be' will fold into the 'cdn' key over time as well, assuming we're successful with the single-backend model in T288106. As we're in transition and testing, we'll probably need scripts and tools to unify the pool state of 'ats-be' and 'cdn' anyways, just for the single-backend tools (because the single-backend model, stopping an ats-be necessarily impacts the traffic of the haproxy and varnish instances on the same node, since the local ats-be is their *only* backend cache), but simplifying and unifying the two front-edge keys first makes the most sense.