Candidate Configuration and compare_config()

get_config(): three configs, normalized

get_config's real signature and return type, installed napalm 5.2.0

def get_config(
  self, retrieve: str = "all", full: bool = False,
  sanitized: bool = False, format: str = "text",
) -> ConfigDict: ...

# ConfigDict's real fields, verified via inspect:
# running: str, startup: str, candidate: str

Verified directly. get_config() is itself a getter (its name starts with get_) -- same normalization principle as Lesson 3, applied to configuration text instead of facts/interfaces.

output — real, verified

get_config keys: ['running', 'candidate', 'startup']
get_config['running'] (truncated): hostname SW1
interface GigabitEthernet0/

Real, verified output. Unlike get_facts()/get_interfaces(), get_config()'s values are configuration text, not further-structured fields -- normalized at the level of 'which config are you asking for,' not the text's internal syntax.

Quick checkConcept check

What does get_config() normalize, compared to get_facts()/get_interfaces()?

Nothing -- get_config() is identical across vendors down to the exact syntaxWhich configuration you're asking for (running/startup/candidate) as a consistent three-key dict -- the configuration text itself remains vendor-specific syntax, unlike get_facts()'s fully-structured fieldsIt converts all vendor configs into YAMLIt only works on Cisco devices

Loading a candidate: merge vs. replace

real signatures, installed napalm 5.2.0

def load_merge_candidate(self, filename=None, config=None) -> None: ...
def load_replace_candidate(self, filename=None, config=None) -> None: ...

Verified directly. Both stage a candidate configuration without touching the running config -- merge adds/changes just the given lines; replace treats the given config as the device's entire intended configuration.

real, verified execution

driver.load_merge_candidate(config="vlan 20\n name VOICE\n")
diff = driver.compare_config()
print(repr(diff))

Staging a candidate never touches the device's actual running configuration -- confirmed directly: nothing changes until commit_config() (Lesson 5).

Quick checkScenario

What's the real difference between load_merge_candidate() and load_replace_candidate()?

There is none -- they behave identicallymerge adds/changes only the given configuration lines on top of what's already running; replace treats the given configuration as the device's complete intended state, discarding anything not includedmerge is for Cisco, replace is for Juniperreplace only works with get_facts()

compare_config(): the diff, before anything changes

compare_config's real signature — checked on the actual IOS driver, not just the mock

def compare_config(self) -> str: ...

Verified directly against IOSDriver (the real driver class), not just NAPALM's mock -- takes no arguments. A candidate must already be loaded via load_merge_candidate()/load_replace_candidate() first.

output — real, verified

'+vlan 20\n+ name VOICE'

Real, verified diff output -- a plain string, unified-diff-style, showing exactly what would change if committed.

The same principle, a third real implementation

Reliable Automation (Phase 2.8) taught dry-run mode by hand: check what would change before changing it. Ansible (Phase 3.0) offered the same guarantee through --check mode. compare_config() is NAPALM's own real implementation of the identical principle -- see the diff, review it, then decide whether to commit or discard (Lesson 5).

Quick checkConcept check

What principle does compare_config() implement, already taught twice in this curriculum under different names?

A completely new concept unique to NAPALMDry-run / check-mode: see exactly what would change before committing to the change -- Reliable Automation's dry-run mode and Ansible's --check mode are the same underlying principle, now a third real implementationLoad balancing across multiple devicesAutomatic rollback on failure

Quick checkPredict output

A script calls driver.compare_config() without first calling load_merge_candidate() or load_replace_candidate(). Based on what this lesson verified about the candidate-config workflow, what would you expect?

A meaningful diff showing recent changes to the running configAn empty or meaningless diff, since compare_config() compares the candidate configuration against the running one -- and no candidate was ever stagedThe device automatically loads a default candidatecompare_config() would connect to the device for the first time

Key takeaways

get_config() normalizes which configuration you're asking for (running/startup/candidate as a fixed three-key dict) -- the text itself stays vendor-specific syntax.
load_merge_candidate() stages additive changes; load_replace_candidate() stages a full intended-state replacement -- verified as genuinely different operations, not interchangeable.
compare_config() takes no arguments on the real driver interface and returns a real diff string -- verified directly, never invented.
compare_config() is dry-run mode (Phase 2.8) and check mode (Phase 3.0)'s underlying principle, implemented natively by NAPALM -- review the diff before Lesson 5's commit or discard.

What you'll learn

get_config(): three configs, normalized

Loading a candidate: merge vs. replace

compare_config(): the diff, before anything changes