Problem
On upgrade, Infix migrates startup-config to the new syntax and writes the result back to disk immediately. If confd then fails to parse the migrated file — or the upgrade fails for any other reaso, the system falls back to failure-config.
If the user can't log in to troubleshoot from fail-safe mode, the natural recovery path is to reboot into the secondary A/B partition, which runs the previous (working) Infix version. But by then startup-config has already been overwritten with the migrated syntax. The old confd can't parse it either, so the secondary boot also falls back to failure-config.
Net effect: a failed migration can strand the user with no working config on either partition, even though the actual config that worked pre-upgrade still logically exists — it's just been clobbered.
Proposal
Don't persist the migrated config to startup-config as part of the upgrade path. Migrate in memory / into the running config only. Leave the on-disk startup-config in its original (old) syntax until the user explicitly commits:
copy running-config startup-config
This makes the A/B fallback safe again: the secondary partition always finds a startup-config it can parse, because migration never touched disk. The user is expected to log in post-upgrade, verify the running config, and save it themselves once satisfied.
Open questions
Do we want any signal/alarm that running != startup post-migration, beyond CLI/banner?
Independent of the above, once an upgrade is confirmed successful, the user should be prompted/reminded to also upgrade the secondary (now-inactive) partition. Otherwise the secondary keeps running an old Infix version indefinitely, and a future fallback to it lands on stale software as well as stale config. Worth deciding whether this is a CLI hint, a login banner, or something more automatic even?
Trade-offs
- Adds a manual step post-upgrade:
startup-config stays on old syntax until the user runs copy running-config startup-config themselves — either right after upgrade, or implicitly the next time they save any config change. This is not a problem for unattended/zero-touch upgrades: confd already detects a stale infix-meta:version in startup-config at every boot and re-migrates into running config regardless, so the system keeps working across reboots even if the file on disk is never updated.
- Alternative considered: keep saving the migrated file, but only after confirming
confd can parse it back (round-trip validate before commit to disk), combined with keeping a .pre-migration backup of the old file for manual recovery. More automatic, but more complex, and still doesn't close the A/B gap — the old-version confd on the secondary can't read the new syntax regardless of how well the new-version confd validated it.
- We should decide whether to solve this in general (any config migration) or scope it strictly to the startup→new-syntax upgrade migration case.
Problem
On upgrade, Infix migrates
startup-configto the new syntax and writes the result back to disk immediately. Ifconfdthen fails to parse the migrated file — or the upgrade fails for any other reaso, the system falls back tofailure-config.If the user can't log in to troubleshoot from fail-safe mode, the natural recovery path is to reboot into the secondary A/B partition, which runs the previous (working) Infix version. But by then
startup-confighas already been overwritten with the migrated syntax. The oldconfdcan't parse it either, so the secondary boot also falls back tofailure-config.Net effect: a failed migration can strand the user with no working config on either partition, even though the actual config that worked pre-upgrade still logically exists — it's just been clobbered.
Proposal
Don't persist the migrated config to
startup-configas part of the upgrade path. Migrate in memory / into the running config only. Leave the on-diskstartup-configin its original (old) syntax until the user explicitly commits:This makes the A/B fallback safe again: the secondary partition always finds a
startup-configit can parse, because migration never touched disk. The user is expected to log in post-upgrade, verify the running config, and save it themselves once satisfied.Open questions
Do we want any signal/alarm that running != startup post-migration, beyond CLI/banner?
Independent of the above, once an upgrade is confirmed successful, the user should be prompted/reminded to also upgrade the secondary (now-inactive) partition. Otherwise the secondary keeps running an old Infix version indefinitely, and a future fallback to it lands on stale software as well as stale config. Worth deciding whether this is a CLI hint, a login banner, or something more automatic even?
Trade-offs
startup-configstays on old syntax until the user runscopy running-config startup-configthemselves — either right after upgrade, or implicitly the next time they save any config change. This is not a problem for unattended/zero-touch upgrades:confdalready detects a staleinfix-meta:versioninstartup-configat every boot and re-migrates into running config regardless, so the system keeps working across reboots even if the file on disk is never updated.confdcan parse it back (round-trip validate before commit to disk), combined with keeping a.pre-migrationbackup of the old file for manual recovery. More automatic, but more complex, and still doesn't close the A/B gap — the old-versionconfdon the secondary can't read the new syntax regardless of how well the new-versionconfdvalidated it.