I don't really see a reason not to provide this option, even if it is just local.
However, I could see us using a remote git server to actually propagate configs to caches. For instance, every server would get its own branch in the repo, and ORT would periodically pull its server's branch to get new configs. Queueing updates for a server would trigger `atstccfg` to generate all the config files for that server, then `git add` and `git commit` the changes to the server's branch. That way, only diffs would need to be propagated to servers, rather than the entire set of Traffic Ops data required to generate all of the config files for a given server. This would reduce resource usage on the caches, as well as reduce load on the Traffic Ops database, because we'd only need to make one set of queries in total rather than one set of queries per server. This would allow us to propagate changes to the CDN much faster than we do today, with even less performance required of the Traffic Ops database server. - Rawlin On Tue, Mar 16, 2021 at 2:01 PM Robert O Butts <[email protected]> wrote: > > I'd like to propose adding a feature to ORT/t3c to track config changes in > a git repo. > > My plan is to add a flag `--git` with the options yes/no/auto, defaulting > to `auto`. With 'auto' a repo will be committed to if it exists, but not > created. With 'yes' the repo will be created and committed to. With 'no' no > git operations will be performed. > > The idea is, people who want to start using it can either add `--git=yes` > to their server automation (whatever's running ORT/t3c, like cron or > ansible), or simply run it as a one-time command on each server (like with > Ansible Push). After that, if the repo exists, it will automatically be > used. > > Defaulting to auto will prevent any manual runs from accidentally not > committing to the repo if they forget the flag, but will also avoid > creating the repo if it doesn't exist, which some users may not desire. > > Finally, a 'no' option allows any users who are already using git to manage > config and want to continue doing so outside ORT/t3c without ATC breaking > and injecting new commits, to do so. > > I believe this will be a big benefit for operations, especially debugging > production issues. For example: > - in an emergency, halt any automation and git checkout to a previous known > good configuration > - use git to see how files changed over time, and see when a breaking > change occurred > - search git, to see all previous values for a particular setting > - correlate historical config changes with CDN traffic behavioral changes > > PR is here: https://github.com/apache/trafficcontrol/pull/5648 > > Does anyone have any objections or concerns with this? Does anyone have > their ATS config directory as a git repo today? Will the above options > break anyone? > > If nobody comments in 72 hours, I'll assume Lazy Consensus. > > Thanks,
