It's entirely local. Basically, ORT/t3c is just doing "git init" and "git commit."
We could make it remote, but that'd be a much larger feature. I'm not sure how useful remote would be, other than maybe for backups. Because every server is going to have slightly different config, you wouldn't want to and couldn't share the exact files between servers. Of course, you could always add your own automation (e.g. Ansible, Puppet) outside ATC to `git remote add` and `git push`. The "big picture" is just making it easier to debug operational history. Again, if something goes wrong, you can restore to a known good state, see what the previous state was, etc. And not just right away, we've had issues in the past that we didn't realize were an issue for months, or noticed a config was wrong (either in TO or generating wrong, could be either), and had no idea if it was ever right. And you can disable it, if that isn't useful to you. On Tue, Mar 16, 2021 at 3:06 PM Eric Friedrich <eric.friedric...@gmail.com> wrote: > Can you explain more about how the git repo works? > > Is it a local repo or a git server somewhere? > > How are configs on different servers stored (diff repos, diff branches, > diff directories, etc...)? > > > It sounds like a useful feature, but I think I'm missing the big picture. > > On Tue, Mar 16, 2021, 4:01 PM Robert O Butts <r...@apache.org> 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, > > >
