Lifecycle on Deevnet IoTaaS

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, so that step is not optional.