Coming in after lots of great comments. For me, the crucial difference between the choice of CLI vs API (I prefer to pretend Web UIs don’t exist) is whether the client is human or not. For hands-on troubleshooting, nothing beats a CLI, mainly because you can decide in the moment which metrics/state you want to interrogate, and make on-the-fly config changes if needed to resolve an outage quickly. Obviously this gets problematic if a device config diverges from a SoT, but reasonable people can disagree on whether it’s worth extending downtime to push config updates through SoT-to-device automation. For normal configuration/provisioning work, best to use an API if you can, even if it’s ncclient to push blocks of text configs to a device. We’ve all copy-pasted blocks of config into devices, but we’ve also all missed a line when doing so and broken a network. And as these configs changes tend to be far more common (and likely more easily templatable), I just don’t see the benefit of doing this sort of work manually if it can be avoided.* That said, I take an expansive view of the definition of automation - expect/paramiko scripts (yes, the CLI can be an API if it’s a machine talking to it), as well as load merging templated config files counts in my opinion. Anyone telling you that only ,say, gNMI counts as a “real” automation solution needs to be ignored with prejudice. -Chris
On Mar 18, 2025, at 12:05, Mark Prosser via NANOG <nanog@lists.nanog.org> wrote:
Hi NANOG community,
I posed this question in several chat groups, but I'd like to get your opinions.
Do you love the CLI? Do you hate the CLI? Would you -- or do you already -- enjoy a world where you never need to touch the CLI, to manage your network?
This applies to both provisioning and troubleshooting; to which, you may have different answers.
So far, I've seen a variety of replies around the usual "should/must/must not/should not".
Warm regards,
-- Mark Prosser // E: mark@zealnetworks.ca // W: https://zealnetworks.ca
_______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/GNZX57LV...