That's a take on it I really hadn't considered. I'm very aware that moving from a decade or two of legacy manual config to full data model/automation in a big bang is never going to work, but I'd been looking at what individual elements could be pulled out and automated with judicious use of "replace". Never considered making the *entire* legacy config a starting point for the template, and then effectively working on automating replacing parts of that config file with data-driven versions of the same.
It really makes life a LOT easier to do it that way. It can create some quirky downsides where different people create the sections to replace in different ways, and operational confusion (Is this section under automation now or not?) , but it's still light years ahead of trying to build a monolithic template from scratch. Working section by section also makes it much easier to handle deltas and exceptions for different sites and locations. On Mon, Dec 12, 2022 at 5:27 AM tim@pelican.org <tim@pelican.org> wrote:
On Saturday, 10 December, 2022 06:47, "Saku Ytti" <saku@ytti.fi> said:
What you can do, day1
a) copy configs as-is, as templates b) only edit the template c) push templates to network
That's a take on it I really hadn't considered. I'm very aware that moving from a decade or two of legacy manual config to full data model/automation in a big bang is never going to work, but I'd been looking at what individual elements could be pulled out and automated with judicious use of "replace". Never considered making the *entire* legacy config a starting point for the template, and then effectively working on automating replacing parts of that config file with data-driven versions of the same.
Food for thought, thanks for that.
Cheers, Tim.