fix(plugins): remove the phantom http plugin; surface orphaned plugin settings
CI / lint (push) Successful in 3s
CI / unit (push) Successful in 46s
CI / integration (push) Successful in 2m22s
CI / publish (push) Successful in 1m16s

Operator saw the `http` plugin -- deleted when ping/dns/http were unified into
the Monitor entity -- still reported as enabled, with no way to clear it.

It was never an orphaned row. `plugin.http` was hardcoded in core DEFAULTS, so
deleting the app_settings row did nothing: the default reasserted it on the
next settings load. That is precisely why no cleanup UI could have fixed it.
Rule 22 says the removed subsystem should have taken its setting with it.

Purged the surviving references -- the DEFAULTS key, "http" in
CAPABILITY_PLUGINS, the stale plugin_manager docstring example, and the
capabilities blurb still advertising HTTP/uptime as a bundled capability --
plus a migration dropping any stored plugin.http row. Untouched: `http` as a
MONITOR TYPE (icmp/tcp/dns/http) everywhere it appears, and http_001_initial,
which is kept deliberately so existing DBs resolve the revision graph.

For the general case, cleanup splits by provenance rather than being uniformly
automatic or uniformly manual:

  Bundled plugins ship in the image and version atomically with core, so they
  cannot be transiently missing -- a plugin.* default with no bundled directory
  is unambiguously a bug. Guarded by a unit test that fails CI, which is the
  only part safe to automate.

  External plugins live in operator-mounted /data/plugins, where absence is
  ambiguous: unmounted volume, failed install, mid-upgrade. Auto-deleting their
  config would silently destroy unrecoverable credentials on a transient
  condition, so Settings now lists them under "Configured but not installed"
  with an explicit, confirmed, audit-logged Remove. The section hides entirely
  when empty, and the remove route refuses if the plugin is actually installed.

Orphan detection reads STORED rows, never the DEFAULTS-merged view -- offering
to remove a default-only key would be a lie -- and returns names only, since
plugin config can hold credentials and listing orphans never needs their values.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-12 23:41:06 -04:00
co-authored by Claude Opus 5
parent 6c9b89390a
commit 59fece855d
7 changed files with 265 additions and 7 deletions
+4 -2
View File
@@ -9,7 +9,9 @@ and a DEFAULTS-merged-with-stored dict, mirroring get_all_settings' merge.
from steward.core import settings as settings_module
from steward.core.settings import DEFAULTS, to_plugins_cfg
DEFAULT_ON = {"docker", "host_agent", "http", "snmp"}
# NB: no "http" — that plugin was dissolved into the unified Monitor entity, and
# its lingering default is what test_plugin_settings_hygiene.py now guards against.
DEFAULT_ON = {"docker", "host_agent", "snmp"}
VENDOR_OPT_IN = {"traefik", "unifi"}
@@ -32,7 +34,7 @@ def test_stored_choice_overrides_default():
cfg = to_plugins_cfg(merged)
assert cfg["docker"]["enabled"] is False
# untouched defaults remain enabled
assert cfg["http"]["enabled"] is True
assert cfg["snmp"]["enabled"] is True
def test_defaults_use_plugin_dot_namespace():