Re: How much do you automate your automation?
Andrew Latham via NANOG <[email protected]>
| Newsgroups | gmane.org.operators.nanog |
|---|---|
| Message-ID | <CA+qj4S_KORSAPVS13ABCAEDJZB8o+r5Dw7PPUbU7UyDXHUV7EA@mail.gmail.com> |
Small note to add here, order of configuration change is possible in automation and configuration management systems. Often the manual MOP/Playbook take for granted the procedural ordering of changes that a configuration management system can apply all at once across the board instantly. I think this very issue has caused some caos for organizations in the past. On Wed, Apr 15, 2026 at 12:59 AM Saku Ytti via NANOG <[email protected]> wrote: > > On Tue, 14 Apr 2026 at 22:37, Jon Lewis via NANOG <[email protected]> wrote: > > > What I'm wondering is, how common is it to take the next logical step and > > if you have a planned maintenance window to implement some simple change, > > do you have an engineer manually make that change, manually execute a > > script that implements the change, or use old-school automation (at) to > > schedule a date & time at which the script that implements the change will > > be run, and optionally have an engineer monitor that the change happened > > and had the intended results? > > If you do deltas, this is a very difficult problem. Trying to > reconcile how to move from A to B. This often leads to a network where > some things are managed by automation, like interface/bgp turn-up, > some things are managed by people. And the true state is the > configuration backup, there is no way to recreate the entire config > from data. > Even the mentioned hyperscalers rarely actually manage 100% of config > via system, they manage DC from system, but edge nodes may use the > above process. > > If you ignore deltas, the problem becomes very simple. That is, if for > any change, changing a dot in the description of one interface you > ship an entire new configuration, and let the router worry about the > reconciliation between the A and B configuration. > > Anyone can get to the latter option with trivial resources and skill, > the former I wouldn't recommend to anyone, no matter how well > resourced. > > The process to get to the latter is > > 1. put your configuration backups in your network configuration directory > 2. edit the configuration file when needed > 3. push the configuration file > > Now 100% comes from the system, and anyone can do this literally in minutes. > > Of course you're not exactly reducing much work here at all. But the > point is, it doesn't need to be a risky project which may or may not > deliver something. You can start today, and manage 100% of config in > the system. Then one by one pick low hanging fruits, remove them from > the flat file, generate them from SQL, and create the final > configuration using the flat file + generated config. > Now you always know what the network state is, there is no need for > the flat file to ever be zero, that's not important. > > This deltaless configuration used to be quite poorly supported by > vendors, but today it is nearly universally supported (Junos, SROS, > IOS-XR, EOS all work), IOS-XE I'm not entirely sure if it works or > not. > > -- > ++ytti > _______________________________________________ > NANOG mailing list > https://lists.nanog.org/archives/list/[email protected]/message/AEQMBR7YOYGY6KLVKDQL42VAC6EHYLB5/ -- - Andrew "lathama" Latham - _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/TUO2KPSIPGXYDNVP7BNSNKJCJMWQXGIF/