Why Multi-vendor Automation Is Hard, and How nornir_napalm Closes the Gap

Two capabilities, still not connected

Two different axes, still separate

Nornir (Phase 3.4) answers "how do I execute operations across many devices?" NAPALM (Phase 3.5) answers "how do I read/change state through one normalized API?" Neither module ever connected the two -- every Nornir task in Phase 3.4 ran vendor-specific commands; every NAPALM example in Phase 3.5 talked to exactly one device by hand.

Without this module -- three separate scripts

Cisco scriptNetmiko or NAPALM's IOS driver, by hand
Arista scripta different driver, by hand
Juniper scriptyet another driver, by hand
Three code paths, three loops to maintain

With nornir_napalm -- one workflow

One Nornir inventoryeach host lists its own platform
One nr.run(task=napalm_get, ...)same call, every host
One code path, any number of vendors

Quick checkConcept check

What capability is still missing after Nornir (Phase 3.4) and NAPALM (Phase 3.5), taken individually?

Nothing -- Nornir alone already handles multiple vendorsRunning one normalized operation across a fleet where different hosts are different vendors -- Nornir orchestrates but stays vendor-specific per task; NAPALM normalizes but only talks to one device at a timeNAPALM cannot connect to more than one device, periodNornir cannot filter an inventory

nornir_napalm: a real, thin plugin -- not a new framework

nornir_napalm's real module structure, installed nornir_napalm 0.6.0

nornir_napalm.plugins.connections
nornir_napalm.plugins.tasks.napalm_cli
nornir_napalm.plugins.tasks.napalm_configure
nornir_napalm.plugins.tasks.napalm_confirm_commit
nornir_napalm.plugins.tasks.napalm_get
nornir_napalm.plugins.tasks.napalm_ping
nornir_napalm.plugins.tasks.napalm_rollback
nornir_napalm.plugins.tasks.napalm_validate

Real, verified via pkgutil.walk_packages against the installed package -- one connection plugin, seven task functions. Nothing hidden, nothing larger than this.

This module's actual scope, stated honestly

Of these seven tasks, this module covers exactly two in depth: napalm_get (Lesson 3) and napalm_configure (Lesson 4). napalm_cli, napalm_ping, napalm_rollback, napalm_confirm_commit, and napalm_validate are real and confirmed to exist, but are not separate lessons here -- covering all seven would turn this module into a catalog rather than teaching the one capability that matters: composition.

Quick checkScenario

A learner expects this module to re-explain InitNornir(), nr.filter(), or get_network_driver() from scratch. What should they expect instead?

A full repeat of Nornir Lesson 2 and NAPALM Lesson 2, for reviewThose are assumed already known from Phase 3.4/3.5 and are not re-taught -- this module only covers the integration layer connecting them (nornir_napalm's connection plugin and task functions)This module doesn't use Nornir's inventory at allThis module replaces get_network_driver() with a new mechanism

Verified compatible, not assumed

real, verified install -- zero conflicts

pip install nornir==3.6.0 napalm==5.2.0 nornir-netmiko==1.0.1
pip install nornir_napalm

# pip list afterward:
# nornir            3.6.0   <- unchanged
# napalm            5.2.0   <- unchanged
# nornir_napalm     0.6.0   <- new

Verified directly in an isolated environment: nornir_napalm installs cleanly alongside the exact Nornir and NAPALM versions already used in Phase 3.4/3.5, with no version changes to either.

Quick checkPredict output

Based on the real, verified install above, what happened to the already-installed nornir (3.6.0) and napalm (5.2.0) versions when nornir_napalm was added?

Both were silently upgraded to newer versionsNothing -- both stayed at their exact existing versions; nornir_napalm installed cleanly alongside them with no conflictsnapalm was downgraded to be compatiblenornir_napalm failed to install and required a different Nornir version

Quick checkConcept check

Is nornir_napalm best understood as a new automation framework?

Yes -- it replaces both Nornir and NAPALM with something newNo -- it's a thin plugin: one connection plugin (selecting a NAPALM driver from inventory) plus seven task functions wrapping NAPALM's own methods. Nornir orchestrates, NAPALM normalizes state; nornir_napalm connects the two without adding new concepts of its ownYes, because it introduces its own inventory formatNo, because it doesn't use Nornir's task model at all

Key takeaways

The missing capability, precisely: running one normalized operation across a fleet where different hosts are different vendors -- neither Nornir nor NAPALM alone does this.
nornir_napalm is a real, thin plugin -- one connection plugin, seven task functions -- verified directly from the installed package, not a new framework.
This module covers exactly two of those seven tasks in depth (napalm_get, napalm_configure) -- the rest are real but explicitly out of scope, to avoid becoming a catalog.
nornir==3.6.0, napalm==5.2.0, and nornir_napalm==0.6.0 install and coexist cleanly -- verified directly, no version changes to existing dependencies.

What you'll learn

Two capabilities, still not connected

nornir_napalm: a real, thin plugin -- not a new framework

Verified compatible, not assumed