Skip to content

slm/secrets: secret updates don't propagate to running services — rotation requires a full role redeploy via the mislabeled 'Migrate' button #11719

Closed

Description

@mrveiss

Problem

Updating a system secret in the SLM UI (/slm/settings/admin/secrets, e.g. hf_token) changes only the DB row. The value reaches consuming services (TTS worker env file, backend env, …) only as an Ansible extra_var during a full role deploy (services/ansible_secrets.fetch_deploy_secrets → templates → .env). There is no "apply/propagate secrets" action, so rotating a token requires knowing that:

  1. the roles page "Migrate" button (RolesView.vue) doubles as an in-place redeploy when you pick the node the role already runs on, and
  2. a full role redeploy (venv rebuild, package installs, model predownload, service restart) is the only way to deliver a one-line env change.

That is disproportionate and undiscoverable — surfaced while diagnosing the invalid HF token case (#11718): even after fixing the stored token, nothing on the secrets page tells the operator the running worker still has the old value.

Expected

A lightweight secret-propagation path, e.g. one of:

  • an "Apply to services" action on the secrets page that re-renders only the env-file templates of dependent roles and restarts the affected services (tag-limited ansible run, tags: ['deploy']-style, no venv/model work), or
  • deploy-time-free consumption: services read managed secrets from SLM at startup via the existing internal API, so a secret update + service restart suffices, or
  • at minimum: after saving a secret, the UI lists which deployed services still hold a stale value and offers the redeploy per role.

Fits under the #10088 umbrella (rotation impact list / cache invalidation) as the SLM-fleet propagation slice; the roles-page "Migrate" naming/affordance gap ("Redeploy" for same-node) is part of the UX fix here.

ACs

  • Rotating a system secret can be applied to all dependent running services without a full role redeploy
  • Secrets page shows propagation state (which services are current vs stale) after an update
  • Roles page exposes an explicit "Redeploy" affordance (same-node migrate) instead of only "Migrate"

Activity

  1. github-actions commented on Jul 15, 2026

    @github-actions
    Contributor

    PR #11728 (merged to Dev_new_gui) references this issue with a close keyword.

    feat(slm/secrets): apply-secrets propagation without full role redeploy + roles-page Redeploy (#11719)

    If this issue is fully resolved, close it manually. If work remains, no action is needed.

  2. mrveiss commented on Jul 15, 2026

    @mrveiss
    OwnerAuthor

    Closed — merged to Dev_new_gui via PR #11728, squash commit 65b9913dc.

    AC evidence (verbatim):

    • "Rotating a system secret can be applied to all dependent running services without a full role redeploy" — ✅ POST /api/secrets/apply + ansible/apply-secrets.yml (env re-render + service restart only; no venv/packages/model steps); secret→role mapping _SECRET_TO_DEPENDENT_ROLES beside _SECRET_TO_ANSIBLE_VAR (single source of truth). autobot_internal_api_key documented-excluded (fans out across backend.env/nginx/slm-agent — no single clean template target).
    • "Secrets page shows propagation state (which services are current vs stale) after an update" — ✅ SecretsSettings.vue: per-row Apply-to-services for mapped keys, stale-value hint after save, apply-result panel.
    • "Roles page exposes an explicit 'Redeploy' affordance (same-node migrate) instead of only 'Migrate'" — ✅ RolesView.vue Redeploy button, same dialog/endpoint, current node preselected when determinable.

    Verification: pytest tests/api/test_apply_secrets.py → 9 passed (re-run by main session post-rebase); vue-tsc clean; playbook --syntax-check clean; CI 29 pass / 0 fail on merge tip.
    Integration: endpoint wired into canonical PlaybookExecutor (auto-injects fetch_deploy_secrets); UI calls it via useSecretsApi.

    Discoveries: #11727 (pre-existing i18n debt in SLM frontend views), #11735 (executor passes secret extra_vars as argv — pre-existing, HIGH), brittle-assertion note added to #11248. Gate 2 (dangling refs) clear.

  3. mrveiss commented on Jul 16, 2026

    @mrveiss
    OwnerAuthor

    Note (2026-07-16): the Redeploy button shipped here reuses POST /roles/{name}/migrate, which was broken by a pre-existing extra_var mismatch — every redeploy hard-failed on role_name parameter is required. Fixed in #11782 (PR #11784, c4a7977e5) and verified live: tts-worker redeploy now returns success/rc=0 with ok=32 changed=13 failed=0. The Redeploy affordance is functional end-to-end as of that fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions