Why Templates Matter

The problem with a hardcoded string

Every configuration push so far in this curriculum has looked like this:

push_ntp.py — Netmiko Fundamentals, Lesson 4

config_commands = [
  "ntp server 192.168.1.1",   # placeholder IP
]

connection.send_config_set(config_commands)

A single, fixed configuration line, hardcoded directly into the script.

That works for one line on one device. Now picture a real access-layer rollout: 50 switches, each needing its own set of VLANs — different IDs, different names, some switches needing three VLANs, others needing five. Hardcoding each switch's block as its own Python string means 50 near-identical blocks, each one a chance to typo a VLAN ID or forget a switch entirely.

Quick checkConcept check

What's the core problem with hardcoding each device's configuration as its own Python string, once you have more than a handful of devices?

Python can't store more than a few strings at onceIt doesn't scale — the same near-identical block gets copy-pasted per device, and every copy is a chance to introduce a mistakesend_config_set() only accepts one device's configuration per script runHardcoded strings are slower to execute than templates

A better shape for the same problem

This has a familiar answer already. "Functions & Reusable Automation Logic" made exactly this case for Python code: one function definition, called from many places, instead of the same logic copy-pasted at each call site. Templating is that same idea, applied to configuration text instead of Python logic — one template, rendered once per device, driven by that device's own data.

Hard-coded configuration

One Python string per deviceSW1's block, SW2's block, SW3's block...
Every device-specific value typed by hand
A typo or missed device hides in the copy-paste

Templated configuration

One template, many devicesthe structure is written once
Device-specific values come from dataa dict or list, not hand-typed text
The same template produces every device's config

Quick checkIdentify the correct code

A team needs to configure VLAN 10 named USERS on 40 switches. Which approach is what this module is building toward?

A Python string per switch: sw1_config = "vlan 10\n name USERS", sw2_config = "vlan 10\n name USERS", ...One template file with {{ }} placeholders, rendered once per switch using each switch's own dataTyping the configuration manually into each switch's terminalA single Python string shared by all 40 switches, with no placeholders at all

The full progression this module builds

Hard-coded configurationone Python string per device — where this curriculum starts
Repeated Python stringscopy-pasted per device — the pain point
Structured dataa dict/list describing each device's values
Templatewritten once, describing the shape
Rendered configurationdata + template = real config text
Validation / previewrendered ≠ automatically correct
Safe deploymentReliable Automation's dry-run/retry/post-check, unchanged

This is not a new project

This module extends the exact project Reliable Automation built — the same inventory format, the same retry policy, the same dry-run default, the same independent post-check, the same structured result reporting. The only thing that changes is where the configuration content itself comes from: instead of a hardcoded f-string, it's rendered from structured data through a template. Everything about deploying it safely stays exactly as Reliable Automation left it.

Quick checkConcept check

Which stage in the progression above is where a network engineer's own device data (VLANs, hostnames, per-site values) actually lives?

The template stageThe structured data stage — the template stays the same for every device; the data is what changesThe validation stageThe safe deployment stage

What doesn't change

send_config_set() itself is untouched — it still takes a list of configuration-mode command lines, exactly as "Making Configuration Changes Safely" taught it. What changes is how that list gets built: instead of typing ["ntp server 192.168.1.1"] by hand, it becomes the rendered output of a template, split into lines. The retry policy, the dry-run default, the pre-check/post-check pattern, and the structured result classification from Reliable Automation don't need to know or care whether the configuration they're applying came from a hardcoded string or a rendered template — that boundary is exactly where this module plugs in.

Quick checkMyth check

Does this module replace Reliable Automation's retry policy, dry-run mode, or post-check verification with something new?

Yes — templating requires an entirely different safety modelNo — all of that stays exactly as Reliable Automation built it; this module only changes how the configuration content itself is producedYes, but only the retry policy changesNo, but dry-run mode no longer applies once templates are involved

Key takeaways

Hardcoded, copy-pasted configuration strings don't scale past a handful of devices — every copy is a chance for a mistake.
Templating solves this the same way reusable functions solved repeated Python logic: one definition, driven by per-device data.
This module's full progression: hard-coded config → repeated strings → structured data → template → rendered config → validate/preview → safe deployment.
This is an extension of Reliable Automation's project, not a new one — the retry/dry-run/post-check/reporting machinery is untouched.
send_config_set() itself never changes — only how the list of commands passed to it gets produced.

What you'll learn

The problem with a hardcoded string

A better shape for the same problem

The full progression this module builds

What doesn't change