Software Discovery: Project Plan #

Know what software is actually running, and hear about what upstream has released for it. This is the Discovery stage of Lifecycle Management, built.

Roadmap item: Software Discovery

✓ 3 | ↻ 0 | ⏳ 7 (10 total)

Legend: ✅ Complete | 🔄 In Progress | ⏳ Planned

Project Vision & Scope #

The Software Catalog is the system of record for versions. Every other page links to it rather than stating a version. Today it is assembled by reading inventory pins, role defaults, lockfiles and change records, which leaves two gaps:

A pin is intent, not fact. It says what the automation deploys, not what is running after a manual upgrade, a failed play or a host rebuilt by hand.
Much is never written down at all. OPNsense’s bundled packages, the FRR on the tenant hypervisor, Podman on the VMs, the OS on three of the four Pis and the Builder’s own Fedora release are all “not recorded” in the catalog today.

A discovery run reads each system and produces a dated report of what it found, compared with the catalog. The operator then updates the catalog from the report, or opens a change for the drift.

In Scope

Read-only collection from every substrate system the Builder can reach, with the credentials automation already holds
Versions only: licenses and support models stay hand-maintained in the catalog
A comparison against the catalog and against the inventory pins

Out of Scope

Upgrading anything. Discovery reports; changes go through change management.
Tenant workloads. What a tenant runs is the tenant’s to track.
The travel router, which automation doesn’t manage. It stays a manual entry.

Catalog as data ✅ #

✅ Move the catalog’s rows into a data file the page renders from, so a report can be compared with it mechanically. The page’s grouping, columns and version-source terms stay as they are.

Collectors ⏳ #

One collector per kind of system, each read-only:

⏳ Core router: opnsense-version -v for the release and base, and pkg info for the bundled packages in use (Kea, Unbound) and every installed os-* plugin. opnsense-diag.sh already gathers the first.
⏳ Hypervisors: pveversion -v, which covers Proxmox VE, the kernel, FRR and the SDN packages.
⏳ Substrate service VMs and the Builder: /etc/os-release, the kernel, the Podman version, and the image of every running container, read from the container and not from the unit file.
⏳ Network devices: the switch’s show system-info, and the controller and AP versions from the Omada Open API.
⏳ Raspberry Pis: /etc/os-release and the kernel, for every Pi that answers. A Pi that doesn’t answer is reported as unreachable, not skipped silently.

Report and cadence ⏳ #

⏳ One dated report per run, listing for each item the observed version, the catalog’s version and the inventory pin, with every mismatch called out.
⏳ Run it as part of Build Verification, and after any change record that upgrades something, so the catalog is updated in the same change.

Hearing about new versions and advisories is Patch Awareness.

Pins and licenses of Deevnet’s own software ✅ #

Found while writing Deevnet Software, and listed in the catalog’s Gaps.

✅ Pin what is deployed as -latest: deevnet-broker-account (the vernemq role), deevnet-log-user (the victorialogs role), and the deevnet-kit, deevnet-log-user and deevnet-log-bridge binaries the Pi backend image fetches. Move the reference tenant’s provider constraint from ~> 0.1 to the 0.4 line it actually runs, and its README with it. Each is pinned to the file -latest pointed at; the reference tenant had already moved to ~> 0.5, locked at 0.5.0
✅ License every in-house repository: add a LICENSE file to deevnet-provisioning-api, terraform-provider-deevnet, deevnet-log-bridge, deevnet-container-image-factory and the tenant repositories, and make galaxy.yml agree with LICENSE in the deevnet.mgmt and deevnet.net collections. Every Deevnet repository is Apache-2.0