+1 to adding this as a local option. It could be a good stepping stone for something like Rawlin is suggesting.
On Tue, Mar 16, 2021 at 16:46 Rawlin Peters <[email protected]> wrote: > 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, >
