Lifecycle on Deevnet Infrastructure Platform

Patching

Mon, 01 Jan 0001 00:00:00 +0000

Patching #

Day 2 maintenance and security updates for substrate hosts.

Status: Planned #

This section will document:

Online patching (hosts with internet access)
Offline patching (air-gapped site)
Local dnf mirror setup for full air-gap

Decision Required #

Post-install updates currently require internet access. Options:

Option	Pros	Cons
Accept internet required	Simple, no extra storage	Not true air-gap
Full local dnf mirror	True air-gap	~200GB per Fedora release
Hybrid (security only)	Balanced	Complex to maintain

Current State #

Install-time packages come from ISO/cdrom (air-gap ready).

Inventory Lifecycle

Mon, 01 Jan 0001 00:00:00 +0000

Inventory & Lifecycle Management #

Documents how infrastructure assets are tracked, managed, and retired.

Scope #

This section includes:

Host identity and inventory sources of truth
Hardware lifecycle stages (active, standby, retired)
Image and configuration lifecycle expectations
Decommissioning and cleanup principles

This section ensures infrastructure ages intentionally, not accidentally.

Lifecycle Stages #

Stage	Description
Provisioning	Host being set up, not yet in service
Active	In production use
Standby	Available but not currently assigned
Maintenance	Temporarily offline for updates/repairs
Retired	Decommissioned, removed from inventory

Inventory Sources of Truth #

ansible-inventory-deevnet - Canonical host identity
OPNsense - Authoritative DNS/DHCP (production)
Bootstrap node - Authoritative DNS/DHCP (during provisioning)

Decommissioning #

When retiring a host:

Omada Controller Upgrade

Mon, 01 Jan 0001 00:00:00 +0000

Omada Controller Upgrade #

How the Omada controller on the builder is upgraded to a new version in place, keeping its data. Each upgrade is a change: open a change record of type Upgrade. Its steps are the ones below.

If an upgrade goes wrong, or the controller’s data is damaged, see Omada Controller Recovery.


Runs as	`mbentley/omada-controller` under podman, `omada-controller.service`, on `dv00bld001p01`
Data	`/opt/omada-controller` (`data`, `work`, `logs`)
Snapshots	`/opt/omada-controller-backup/`
Images	Tarballs on the artifact server, declared in `artifacts_podman_images` (`group_vars/artifact_servers.yml`)
Version pin	`omada_image_tag` in `group_vars/network_controllers/vars.yml`

**An upgrade is one-way.** The first start on a new version upgrades the database, and an older controller cannot open it afterwards. The only way back is the snapshot taken in [step 2](#2-record-stop-snapshot), so that step is not optional. Do **not** use `playbooks/upgrade-omada.yml` in the builder collection. It hard-codes a fresh install and deletes the data directories.

Choosing the version #

Pin the build, not a tag family. Use the exact version tag (for example 6.3.0.45), not 6.3 and never latest, so a rebuild restores what was verified.
Check what the devices need. Switch and AP release notes name a recommended controller version. Read them before choosing a target.
A controller major version can bring a MongoDB major upgrade. Controller 5 to 6 did, and the image documents a separate migration for it. This procedure covers upgrades within a MongoDB major version only. Compare mongod --version in the old and new images first.
A new release is a risk of its own. When the target is only days old, stage the previous mature release as a fallback as well, so the way back does not have to be fetched on the day.

1. Stage the image #

Declare the image in artifacts_podman_images and pull it while the controller is still running, so the outage covers only the swap: