[j-nsp] Network automation vs. manual config

[Jason Lixfeld]

I’ll admit that I haven’t done much automation yet, so take this with a grain of salt and provide clue where required...

> On Aug 17, 2018, at 6:54 AM, Antti Ristimäki <antti.ristimaki at csc.fi> wrote:
> 
> Hi colleagues,
> 
> This is something that I've been thinking quite a lot, so I would be delighted to hear some comments, experiences or recommendations. 
> 
> So, now that more and more of us are automating their network, there will be the question about how to manage the configurations, if they are partially automated and partially manually maintained. This will be the case especially while transitioning from a pure CLI jockey network towards a more automated one. There are probably multiple approaches to solve this, but below are a few of them:
> 
> One option is to generate the whole config automatically e.g. from a template or a database and just _not_accepting_ any manual configurations at all. Then when there are needs to do something custom not yet supported by the automation tools, instead of manually configuring it one would take some additional time and build the support into the automation tools. The cost for this might be that deploying something new/custom/tailor-made might take a bit more time compared to just manually configuring it, but in a long run the benefits are obvious. I'm personally preferring this approach.
> 
> Generating the _whole_ configuration automatically off-line from the scratch makes it also easy to remove elements from the configuration, as the auto-generated config can completely replace the existing running-config.

Maybe I’m missing an implied exception, but every once in a while one needs to make some sort of manual configuration to resolve a time sensitive some corner case that the provisioning system doesn’t support because someone external to you (ie: customer, IXP participant) changed something.  How is that handled in this use case?

> If the above mentioned is not doable for the entire configuration, one can take one configuration hierarchy level at a time and automate it, after which no manual configurations will be accepted under that hierarchy. This is rather trivial especially for those configuration hierarchies that tend to be static most of the time.
> 
> Another option is to apply the auto-generated configuration via apply-groups and apply all manual configurations explicitly so that the automatic and manual configurations merge with each other. The positive side of this approach is that it makes easy to develop the automation tools so that manual configs are not overridden by auto-generated config, but I personally see somewhat inconvenient that one really doesn't see the effective running-config when using apply-groups, unless one remembers to display inheritance.
> 
> Any thoughts appreciated.

I tend to agree with you in that apply-groups can make things really hard to follow and make the config explode in size when you try to display inheritance.  So maybe it makes sense at this point to just ignore the CLI all together?  If you have a tool that is going to write your configs with apply-groups our whatever, it can probably display that configuration in whatever format you want so the CLI becomes somewhat obsolete for config review.

And, if you have all that in place, I’m sure this display interface can, and would likely be a single pane of glass for all of your configurations.  It would display anything you throw at it in exactly the same format, no matter what sort of device it’s for.

I can certainly see the value in that.

> Antti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp