Driver Selection from Inventory: platform and nornir_napalm's Connection Plugin

The field that was always there, waiting

Not a new inventory field

platform: has been in this curriculum's Nornir inventory since Phase 3.4's groups.yaml (platform: cisco_ios) -- but nornir_netmiko never actually read it programmatically; it just documented what kind of device a host was. nornir_napalm is the first place in this curriculum where platform is consumed by code, not just prose.

nornir_napalm's real connection plugin, installed nornir_napalm 0.6.0

def open(self, hostname, username, password, port, platform, extras=None, configuration=None):
  extras = extras or {}
  parameters = {
      "hostname": hostname, "username": username, "password": password,
      "optional_args": {},
  }
  parameters.update(extras)

  network_driver = get_network_driver(platform)
  connection = network_driver(**parameters)
  connection.open()
  self.connection = connection

Verified directly by reading the installed package's real source (nornir_napalm.plugins.connections.Napalm.open). This one line -- get_network_driver(platform) -- is the entire driver-selection mechanism.

Quick checkConcept check

Based on the real source above, what determines which NAPALM driver connects to a given host?

A separate configuration file listing each host's vendorThe host's own platform field in Nornir inventory, passed directly into NAPALM's get_network_driver() -- the exact same function verified in Phase 3.5, now called automatically instead of by handNornir guesses the vendor by pinging the device firstIt's hardcoded to always use the IOS driver

Real inventory: platform, and where fixture/connection data lives

inventory/hosts.yaml -- a real, verified 3-host multi-vendor inventory

SW1:
hostname: SW1
platform: mock
data:
  vendor_label: "Cisco-like"
connection_options:
  napalm:
    extras:
      optional_args:
        path: "fixtures/sw1"

SW2:
hostname: SW2
platform: mock
data:
  vendor_label: "Arista-like"
connection_options:
  napalm:
    extras:
      optional_args:
        path: "fixtures/sw2"

SW3:
hostname: SW3
platform: mock
data:
  vendor_label: "Juniper-like"
connection_options:
  napalm:
    extras:
      optional_args:
        path: "fixtures/sw3"

platform: mock for all three -- resolving to NAPALM's real mock driver either way (Lesson 3 explains why). data.vendor_label is a custom field (the same free-form data: mechanism from Phase 3.4) used only for this lesson's own narrative -- not a real NAPALM or Nornir concept.

Designed to resemble, not verified against

vendor_label is a label this lesson author chose. The mock driver doesn't know or enforce anything vendor-specific -- SW1/SW2/SW3's fixture content (Lesson 3) is designed to resemble Cisco/Arista/Juniper's typical output, not independently verified against real Cisco, Arista, or Juniper hardware. No such hardware was available in this authoring environment.

Quick checkScenario

SW1's fixture data looks Cisco-like (interface named GigabitEthernet0/1, an IOS-style os_version string). What's the honest, verified status of that resemblance?

It's fully verified real Cisco IOS behavior, since NAPALM's IOS driver was usedSW1 actually connects through platform: mock, not a real IOS driver -- the fixture content was written to resemble Cisco's typical output, but this was never independently verified against real Cisco hardware, which was never available hereIt doesn't matter -- all vendors return identical output anywayNAPALM automatically detects and validates vendor authenticity from fixture content

connection_options.napalm.extras -- real, verified schema

# Napalm.open()'s real "extras" parameter becomes optional_args on the
# NAPALM driver constructor -- confirmed by actually running this and
# reading the mock driver's fixture from fixtures/sw1, exactly as
# configured above.

connection_options.<connection-name>.extras is Nornir's own real per-connection-plugin configuration mechanism -- CONNECTION_NAME is verified to be the literal string 'napalm', confirmed via nornir_napalm.plugins.connections.CONNECTION_NAME.

Quick checkIdentify the correct code

Which key correctly nests fixture-path configuration for nornir_napalm's mock driver in Nornir inventory?

connection_options.napalm.extras.optional_args.pathconnection_options.mock.pathdata.optional_args.pathplatform.optional_args.path

A real, verified failure: missing platform

a genuinely malformed host -- real, verified

BADHOST:
hostname: 10.10.10.250
# no platform: field at all

Run through nr.run(task=napalm_get, getters=['get_facts']) against this inventory -- real, verified output below.

output — real, verified

BADHOST failed: True
exception: ModuleImportError('Please provide a valid driver name.')

Real, verified output. Nornir's per-host result isolation (unchanged since Phase 3.4) catches this cleanly -- a malformed single host never crashes the whole run.

Quick checkPredict output

A 5-host inventory has one host with no platform field set. What happens when nr.run(task=napalm_get, ...) executes against the whole fleet?

The entire script crashes immediately with an unhandled exceptionOnly that one host fails, with a real, verified ModuleImportError('Please provide a valid driver name.') -- the other four hosts' results are unaffected, exactly like any other per-host failure since Phase 3.4Nornir skips the malformed host silently, with no error recorded at allNornir automatically defaults the missing platform to 'ios'

Key takeaways

nornir_napalm's connection plugin selects a NAPALM driver with one real, verified line: get_network_driver(host.platform) -- no dispatch code written by hand.
platform:, already present in Phase 3.4's inventory, is now functionally significant for the first time in this curriculum.
connection_options.napalm.extras (CONNECTION_NAME='napalm', verified directly) carries fixture-path or other driver-specific configuration through Nornir's own inventory schema.
A missing platform produces a real, verified ModuleImportError, isolated per-host by Nornir's existing failure-handling -- not a new pattern, a reapplication of one.

What you'll learn

The field that was always there, waiting

Real inventory: platform, and where fixture/connection data lives

A real, verified failure: missing platform