9f24f8d999
Every action in the allowlist got there because someone hit the failure by hand, recognised the pattern, and wired a job for it. That loop only closes if a person happens to read enough issues to notice the same failure recurring, so a failure nobody reviews twice never earns an action. Until now a diagnosis that fit nothing could only say a human was needed; it could not say what the human should build. An optional suggested_remediation field closes the other half of the loop. When nothing in the allowlist fits, Hermes may name the remediation it believes would work and the evidence that should be required before running it is safe. It lands in the incident issue under a heading that states plainly the remediation does not exist and was not performed, and in the audit event, where the same proposal recurring across unrelated incidents is the evidence that building it is worth the effort. The field is inert by construction. No gate reads it, and an id that is not already allowlisted still fails action_not_allowlisted exactly as before - naming a remediation and being granted one stay different things, and only the second needs a human to change a deployment. It is rejected outright alongside a requested action: the field reports that nothing fit, so something fitting contradicts it, and allowing both would invite a rationale to be attached to a request the gates must judge on evidence alone. The key is optional rather than required so a response written before today still validates unchanged, and unknown keys are still refused. Also names reclaim_workspace_storage, clear_stuck_agent_pods and abort_hung_build in KNOWN_ACTION_LABELS. They were reporting as "unknown" in metrics on any deployment that had not enabled them, which is the one case where you most want to see the real name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ariadne
Ariadne is the Atlas admin and account automation service.
It sits behind the portal and handles the jobs that are annoying or risky to do by hand: approving access, syncing account state, rotating service passwords, cleaning stale Kubernetes work, checking platform health, and keeping a few service integrations lined up.
How it works
Ariadne is a FastAPI service with a small scheduler. It talks to Keycloak, Vault, Mailu, Nextcloud, Wger, Firefly, Jenkins, Metis, Kubernetes, and a few Atlas-specific services through focused adapters under ariadne/services/.
The API is split between admin routes, account self-service routes, internal event hooks, and Prometheus metrics. Background jobs store run history in the Ariadne database so failures can be inspected later instead of vanishing into logs.
The following are notes for future Brad.
Bring-up dependencies
Ariadne needs:
- Kubernetes API, service DNS, and Ariadne's service account/RBAC
- the Ariadne database, plus the portal database if portal/account sync is enabled
- Vault or the Kubernetes secrets that Vault normally feeds it
- Keycloak/OIDC, because auth and profile sync assume it exists
- ingress/proxy plumbing if humans are going to use it through the portal
- the services for whatever jobs are enabled: Mailu, Nextcloud, Vaultwarden, Wger, Firefly, Jenkins, Metis, OpenSearch, and the comms/game-mode pieces
It can start before every integration is perfect, but the matching scheduled jobs will fail or no-op until their service is actually alive. In a total bring-up, wait for storage, Flux, Postgres, Vault, Keycloak, and ingress first. Afterwards Ariadne becomes useful glue.
Useful routes:
GET /healthGET /metricsGET /api/admin/cluster/statePOST /api/admin/access/requests/{username}/approvePOST /api/account/mailu/rotatePOST /api/account/wger/resetPOST /api/account/firefly/resetPOST /events
Development
python -m pytest
ruff check .
Most runtime behavior is configured through environment variables in ariadne/settings.py. Service-specific logic is in the small adapter modules; ariadne/app.py is focused on request flow and task orchestration.