You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by "Gray, Jonathan" <Jo...@comcast.com.INVALID> on 2021/03/16 21:21:51 UTC
Re: [EXTERNAL] Re: Proposal: ORT/t3c git
Also, DS SSL certificate/key data is considered configuration for ATS. Is that intended to be captured in the git repo, a reference to the riak key version included, or excluded entirely? If it's excluded, wouldn't that create a gap in rollbacks?
Jonathan G
On 3/16/21, 3:06 PM, "Eric Friedrich" <er...@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 <ro...@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://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/5648__;!!CQl3mcHX2A!Rfw4o8SOtvhWXb3hqElHF07XAtr-moe58UJOw41lgQxp2viOS0kBTP9fAC05X5hIOwNR$
>
> 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,
>
Re: [EXTERNAL] Re: Proposal: ORT/t3c git
Posted by Robert O Butts <ro...@apache.org>.
@Jonathan_Gray The current PR commits everything in the ATS config
directory. This excludes any config files outside that directory, and
typically includes SSL certificates and keys. This shouldn't be a security
concern, as the git repo is created with the same permissions as the ORT
script. If a user wants to use git but exclude those, they can simply
create a '.gitignore' matching those files (or any others).
On Tue, Mar 16, 2021 at 3:22 PM Gray, Jonathan
<Jo...@comcast.com.invalid> wrote:
> Also, DS SSL certificate/key data is considered configuration for ATS. Is
> that intended to be captured in the git repo, a reference to the riak key
> version included, or excluded entirely? If it's excluded, wouldn't that
> create a gap in rollbacks?
>
> Jonathan G
>
>
> On 3/16/21, 3:06 PM, "Eric Friedrich" <er...@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 <ro...@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://urldefense.com/v3/__https://github.com/apache/trafficcontrol/pull/5648__;!!CQl3mcHX2A!Rfw4o8SOtvhWXb3hqElHF07XAtr-moe58UJOw41lgQxp2viOS0kBTP9fAC05X5hIOwNR$
> >
> > 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,
> >
>
>