Filtering the Inventory: F() and nr.filter()

A genuinely new capability

Every other lesson in this module maps onto something Phase 3.3 already built by hand. Filtering is the exception — Phase 3.3's package always ran against the whole loaded inventory. Nornir makes targeting a subset a first-class operation.

Quick checkConcept check

Why is filtering called out as the one genuinely new capability in this module, unlike inventory, tasks, or concurrency?

It isn't new — Phase 3.3 had identical filteringPhase 3.3's package always processed the entire loaded inventory; Nornir's nr.filter() adds a first-class way to target a subset, something the hand-built package never didFiltering only exists in Nornir, not in any other automation toolIt's not actually covered in this module

Filtering by custom data

filter_by_site.py

branch1_only = nr.filter(site="Branch1")
print(list(branch1_only.inventory.hosts.keys()))

site is the exact custom data field set on each host in Lesson 2's hosts.yaml -- filtering by it is a direct, meaningful demonstration, not an abstract example.

output — real, verified

['SW4', 'SW5']

Real, verified output. Only Branch1's two hosts match -- HQ's three (SW1, SW2, SW3) are correctly excluded.

Quick checkPredict output

Given the same fleet, what does nr.filter(site="HQ") return?

['SW1', 'SW2', 'SW3']['SW4', 'SW5']All five hostsAn empty list

F() for more flexible queries

nr.filter(field=value) only expresses equality. F() handles richer conditions.

filter_with_F.py

from nornir.core.filter import F

subset = nr.filter(F(name__any=["SW1", "SW4"]))
print(list(subset.inventory.hosts.keys()))

name__any=[...] is one of F()'s query operators -- matches any host whose name is in the given list, spanning both sites at once, something a single nr.filter(field=value) call can't express.

output — real, verified

['SW1', 'SW4']

Real, verified output — one host from each site, selected by an explicit name list rather than a shared field value.

Quick checkIdentify the correct code

Which correctly selects only the single host named SW3?

nr.filter(name="SW3")nr.filter(hostname=3)nr.inventory.hosts["SW3"].filter()nr.filter(F(site="SW3"))

Filtering never mutates the original

verify_no_mutation.py

print("original nr still has all hosts:", list(nr.inventory.hosts.keys()))

Run after every filter above -- real, verified output.

output — real, verified

original nr still has all hosts: ['SW1', 'SW2', 'SW3', 'SW4', 'SW5']

nr.filter() always returns a NEW Nornir object; the original is untouched, confirmed directly — safe to filter repeatedly for different subsets without losing the full inventory.

Quick checkScenario

A script filters nr down to branch1_only = nr.filter(site="Branch1") to run one task, then later needs to run a different task against the full fleet. Does it need to reload the inventory?

Yes — filtering permanently shrinks the original inventoryNo — nr.filter() returns a new object; the original nr still holds all 5 hosts, verified directly, and can be reused or filtered again independentlyYes, but only if more than one filter was appliedIt depends on which filter method was used

Key takeaways

nr.filter(field=value) selects hosts by an exact field match — including custom data fields like site, verified against the HQ/Branch1 grouping.
F() expresses richer queries (like name__any=[...]) that a single equality filter can't.
Filtering always returns a new Nornir object — the original inventory is never mutated, verified directly.
Filtering is the one capability in this module with no Phase 3.3 equivalent — a genuinely new, first-class operation.

What you'll learn

A genuinely new capability

Filtering by custom data

F() for more flexible queries

Filtering never mutates the original