WIP: refactor(hermes): rename chat and triage public hostnames #28

Closed
hermes-automation wants to merge 1 commits from feature/hermes-domain-rename-chat-triage into main

Summary

Renames two public Hermes hostnames across titan-iac:

  • chat.hermes.bstein.devhermes.bstein.dev
  • triage.hermes.bstein.devtriage.bstein.dev

agent.hermes.bstein.dev is deliberately not touched here. That rename is a
separate task/PR and must be mergeable last, because it is the coordinator's own
access point.

This is a repo-only change. Nothing takes effect until this merges and Flux
reconciles. See Rollout below — this rename is not self-contained; it needs a
Keycloak script re-run and certificate issuance to land cleanly.

Pre-flight collision check

Both target hostnames were unused before this change. Verified against
origin/main across tracked files:

  • hermes.bstein.dev (exact host, excluding any *.hermes.bstein.dev) — no matches
  • triage.bstein.dev — no matches

No ingress rule, certificate SAN, CoreDNS entry, or knowledge-catalog entry
claimed either name.

Tooling note for future sweeps: grep -r in this image is ugrep, and when
invoked from the repo root it silently skipped services/hermes/NOTES.md and
the files under services/hermes/skills/. Two live occurrences were missed
that way and were only caught by rendering the ConfigMaps and re-checking with
git grep. Use git grep for repo-wide hostname audits in this repo.

What changed

24 files, 122 insertions / 122 deletions — a symmetric rename with no
incidental edits.

Network and TLS

  • infrastructure/core/coredns-custom.yaml — both host entries at 192.168.22.9, kept in the file's alphabetical order
  • services/hermes/agent-certificate.yaml — SANs on the shared hermes-sites-tls certificate
  • services/hermes/agent-ingress.yamlhermes-sites ingress TLS hosts and both rule hosts

Identity and session

  • services/keycloak/scripts/hermes_access_oidc_ensure.sh — OIDC redirect URI, web origin, root URL and post-logout URI for the chat and triage proxy clients
  • services/hermes/oauth2-proxy.yaml — the chat and triage redirect URLs

The oauth2-proxy deployments use __Host- prefixed cookies with no explicit
cookie domain and no whitelist domain, so no cookie-domain edits were needed.

Application config

  • services/hermes/chat-statefulset.yaml — API server CORS origins and WebUI allowed origins
  • services/hermes/chat-configmap.yaml, services/hermes/configmap.yaml — dashboard public URLs
  • services/hermes/deployment.yaml — triage dashboard public URL, CORS origins, WebUI allowed origins
  • services/maintenance/apps/ariadne-deployment.yaml — the Hermes UI URL printed into proposals
  • services/quality/zap-baseline-configmap.yaml — baseline scan targets

Operator- and agent-facing text

  • services/hermes/configmap.yaml, services/hermes/agent-configmap.yaml — instructions that tell each instance which surface it is
  • services/hermes/NOTES.md, services/hermes/skills/master-hermes-on-atlas/references/architecture.md — operator guide and surface table, both mounted into ConfigMaps
  • services/hermes/router/telegram.go — the two sign-in prompts sent to users
  • dockerfiles/Dockerfile.hermes-agent — the Telegram setup link in the UI
  • dockerfiles/hermes-public-extract/provider.py — outbound User-Agent
  • dockerfiles/hermes-webui-atlas-voice.js — header comment

Generated artifacts — regenerated, not hand-edited

knowledge/catalog/atlas.{json,yaml}, knowledge/diagrams/atlas-http.mmd and
their services/comms/knowledge/ mirrors were produced by the repo's own
renderer (make knowledge, i.e. scripts/render/knowledge_render_atlas.py --write --sync-comms), which also re-sorted the affected entries into their new
alphabetical positions and renamed the diagram node IDs.

One caveat worth knowing: the committed catalogs on main are stale. Running
the renderer on an unmodified main already produces about 1,650 lines of diff
in atlas.json, atlas.yaml, atlas-summary.json and metrics.json that have
nothing to do with this rename. Shipping that here would have buried the rename,
so this PR carries only the rename delta: I rendered both with and without
the hostname change, took the difference between those two renders, and applied
that to the committed files. Each generated file was then checked line-by-line to
confirm every removed line maps to an added line under the hostname substitution
alone. atlas-summary.json and metrics.json are untouched because the rename
does not affect them.

The pre-existing catalog staleness is left for a separate cleanup — it is
unrelated to this change and deserves its own review.

Remaining old-hostname occurrences

One occurrence is intentionally left in place:

  • testing/tests/data/hermes_kanban_card_corpus.jsonl:60 — a frozen corpus of
    historical Kanban cards used as test data. The text records what a past task
    card actually said; rewriting it would falsify a historical record for no
    functional gain.

Nothing else in the repo references either old hostname.

Rollout

Ordering matters — this change is not self-contained.

  1. DNS and certificate first. After Flux reconciles, CoreDNS serves the two
    new names and cert-manager reissues hermes-sites-tls with the new SANs. The
    certificate is shared with agent.hermes.bstein.dev; that SAN is preserved,
    so the agent host is unaffected. Until issuance completes, the new hosts will
    serve a certificate that does not cover them. Wait for the new certificate to
    be Ready before announcing the new URLs.
  2. Re-run the Keycloak ensure script. hermes_access_oidc_ensure.sh must run
    against Keycloak to update the redirect URI, web origins, root URL and
    post-logout redirect URI for the hermes-chat-proxy and hermes-triage-proxy
    clients. Until it does, login at the new hosts fails at the OIDC redirect —
    the manifests will already be pointing at URLs Keycloak does not yet accept.
  3. Users will be logged out. The oauth2-proxy cookies are __Host- prefixed
    and therefore bound to the exact origin, so existing sessions on the old hosts
    do not carry over. Everyone re-logins once at the new hostnames.
  4. The old hostnames stop working once this lands: they are removed from
    CoreDNS, from the ingress rules, and from the certificate SANs.

Old-host redirects: proposed, not included

I have not added redirects from the old hostnames — that is a decision to
make deliberately, not something to slip into a rename.

If you want them, the shape would be a Traefik redirectRegex middleware plus
retained ingress rules for chat.hermes.bstein.dev and
triage.hermes.bstein.dev pointing at the new hosts. The cost is that the old
names must stay in CoreDNS and stay as SANs on the certificate for as long as
the redirects live, which is exactly the state this PR is retiring. My
suggestion, if you want a soft landing: merge as-is, and if the broken
bookmarks turn out to be annoying, add a time-boxed redirect in a follow-up that
also sets the date the old names get dropped. Say the word and I will open that
PR.

Validation

  • kustomize build passes for every touched service: infrastructure/core,
    services/comms, services/hermes, services/keycloak,
    services/maintenance, services/maintenance/apps, services/quality.

  • No old hostname survives in any rendered manifest; agent.hermes.bstein.dev
    still renders 16 times in the Hermes output, unchanged.

  • Full gate (make test) run on this branch and, for comparison, on an
    unmodified origin/main worktree. Identical results — 4 failed, 2614 passed,
    4 skipped on both. After rebasing onto current origin/main (which picked up
    the two new tests from #25) this branch is 4 failed, 2616 passed, 4 skipped,
    with the same 4 failures. They are pre-existing and unrelated to this
    change:

    • two node-capacity tests in test_hermes_agent_layout.py
    • test_http_error_path_redacts_token in test_hermes_gitea_pr_integration.py
    • test_auto_supervise_flag_defaults_false_in_configmap in test_hermes_kanban_supervisor.py

    Ruff also reports the same 3 pre-existing errors on both, in files this PR does
    not touch.

  • sh -n clean on the Keycloak script. The repo has no shellcheck target and
    shellcheck is not installed in this image, so syntax checking is the available
    level of static verification there.

  • gofmt -l clean on the router, and the router still builds with the same
    GO111MODULE=off invocation the Dockerfile uses.

Draft PR — not merging. Over to you.

## Summary Renames two public Hermes hostnames across titan-iac: - `chat.hermes.bstein.dev` → `hermes.bstein.dev` - `triage.hermes.bstein.dev` → `triage.bstein.dev` `agent.hermes.bstein.dev` is deliberately **not** touched here. That rename is a separate task/PR and must be mergeable last, because it is the coordinator's own access point. This is a repo-only change. Nothing takes effect until this merges and Flux reconciles. See **Rollout** below — this rename is not self-contained; it needs a Keycloak script re-run and certificate issuance to land cleanly. ## Pre-flight collision check Both target hostnames were unused before this change. Verified against `origin/main` across tracked files: - `hermes.bstein.dev` (exact host, excluding any `*.hermes.bstein.dev`) — no matches - `triage.bstein.dev` — no matches No ingress rule, certificate SAN, CoreDNS entry, or knowledge-catalog entry claimed either name. > Tooling note for future sweeps: `grep -r` in this image is ugrep, and when > invoked from the repo root it silently skipped `services/hermes/NOTES.md` and > the files under `services/hermes/skills/`. Two live occurrences were missed > that way and were only caught by rendering the ConfigMaps and re-checking with > `git grep`. Use `git grep` for repo-wide hostname audits in this repo. ## What changed 24 files, 122 insertions / 122 deletions — a symmetric rename with no incidental edits. **Network and TLS** - `infrastructure/core/coredns-custom.yaml` — both host entries at 192.168.22.9, kept in the file's alphabetical order - `services/hermes/agent-certificate.yaml` — SANs on the shared `hermes-sites-tls` certificate - `services/hermes/agent-ingress.yaml` — `hermes-sites` ingress TLS hosts and both rule hosts **Identity and session** - `services/keycloak/scripts/hermes_access_oidc_ensure.sh` — OIDC redirect URI, web origin, root URL and post-logout URI for the chat and triage proxy clients - `services/hermes/oauth2-proxy.yaml` — the chat and triage redirect URLs The oauth2-proxy deployments use `__Host-` prefixed cookies with no explicit cookie domain and no whitelist domain, so no cookie-domain edits were needed. **Application config** - `services/hermes/chat-statefulset.yaml` — API server CORS origins and WebUI allowed origins - `services/hermes/chat-configmap.yaml`, `services/hermes/configmap.yaml` — dashboard public URLs - `services/hermes/deployment.yaml` — triage dashboard public URL, CORS origins, WebUI allowed origins - `services/maintenance/apps/ariadne-deployment.yaml` — the Hermes UI URL printed into proposals - `services/quality/zap-baseline-configmap.yaml` — baseline scan targets **Operator- and agent-facing text** - `services/hermes/configmap.yaml`, `services/hermes/agent-configmap.yaml` — instructions that tell each instance which surface it is - `services/hermes/NOTES.md`, `services/hermes/skills/master-hermes-on-atlas/references/architecture.md` — operator guide and surface table, both mounted into ConfigMaps - `services/hermes/router/telegram.go` — the two sign-in prompts sent to users - `dockerfiles/Dockerfile.hermes-agent` — the Telegram setup link in the UI - `dockerfiles/hermes-public-extract/provider.py` — outbound User-Agent - `dockerfiles/hermes-webui-atlas-voice.js` — header comment **Generated artifacts — regenerated, not hand-edited** `knowledge/catalog/atlas.{json,yaml}`, `knowledge/diagrams/atlas-http.mmd` and their `services/comms/knowledge/` mirrors were produced by the repo's own renderer (`make knowledge`, i.e. `scripts/render/knowledge_render_atlas.py --write --sync-comms`), which also re-sorted the affected entries into their new alphabetical positions and renamed the diagram node IDs. One caveat worth knowing: the committed catalogs on `main` are **stale**. Running the renderer on an unmodified `main` already produces about 1,650 lines of diff in `atlas.json`, `atlas.yaml`, `atlas-summary.json` and `metrics.json` that have nothing to do with this rename. Shipping that here would have buried the rename, so this PR carries **only** the rename delta: I rendered both with and without the hostname change, took the difference between those two renders, and applied that to the committed files. Each generated file was then checked line-by-line to confirm every removed line maps to an added line under the hostname substitution alone. `atlas-summary.json` and `metrics.json` are untouched because the rename does not affect them. **The pre-existing catalog staleness is left for a separate cleanup** — it is unrelated to this change and deserves its own review. ## Remaining old-hostname occurrences One occurrence is intentionally left in place: - `testing/tests/data/hermes_kanban_card_corpus.jsonl:60` — a frozen corpus of historical Kanban cards used as test data. The text records what a past task card actually said; rewriting it would falsify a historical record for no functional gain. Nothing else in the repo references either old hostname. ## Rollout Ordering matters — this change is not self-contained. 1. **DNS and certificate first.** After Flux reconciles, CoreDNS serves the two new names and cert-manager reissues `hermes-sites-tls` with the new SANs. The certificate is shared with `agent.hermes.bstein.dev`; that SAN is preserved, so the agent host is unaffected. Until issuance completes, the new hosts will serve a certificate that does not cover them. Wait for the new certificate to be Ready before announcing the new URLs. 2. **Re-run the Keycloak ensure script.** `hermes_access_oidc_ensure.sh` must run against Keycloak to update the redirect URI, web origins, root URL and post-logout redirect URI for the `hermes-chat-proxy` and `hermes-triage-proxy` clients. Until it does, login at the new hosts fails at the OIDC redirect — the manifests will already be pointing at URLs Keycloak does not yet accept. 3. **Users will be logged out.** The oauth2-proxy cookies are `__Host-` prefixed and therefore bound to the exact origin, so existing sessions on the old hosts do not carry over. Everyone re-logins once at the new hostnames. 4. **The old hostnames stop working** once this lands: they are removed from CoreDNS, from the ingress rules, and from the certificate SANs. ### Old-host redirects: proposed, not included I have **not** added redirects from the old hostnames — that is a decision to make deliberately, not something to slip into a rename. If you want them, the shape would be a Traefik `redirectRegex` middleware plus retained ingress rules for `chat.hermes.bstein.dev` and `triage.hermes.bstein.dev` pointing at the new hosts. The cost is that the old names must stay in CoreDNS **and** stay as SANs on the certificate for as long as the redirects live, which is exactly the state this PR is retiring. My suggestion, if you want a soft landing: merge as-is, and if the broken bookmarks turn out to be annoying, add a time-boxed redirect in a follow-up that also sets the date the old names get dropped. Say the word and I will open that PR. ## Validation - `kustomize build` passes for every touched service: `infrastructure/core`, `services/comms`, `services/hermes`, `services/keycloak`, `services/maintenance`, `services/maintenance/apps`, `services/quality`. - No old hostname survives in any rendered manifest; `agent.hermes.bstein.dev` still renders 16 times in the Hermes output, unchanged. - Full gate (`make test`) run on this branch and, for comparison, on an unmodified `origin/main` worktree. Identical results — 4 failed, 2614 passed, 4 skipped on both. After rebasing onto current `origin/main` (which picked up the two new tests from #25) this branch is 4 failed, 2616 passed, 4 skipped, with **the same 4 failures**. They are pre-existing and unrelated to this change: - two node-capacity tests in `test_hermes_agent_layout.py` - `test_http_error_path_redacts_token` in `test_hermes_gitea_pr_integration.py` - `test_auto_supervise_flag_defaults_false_in_configmap` in `test_hermes_kanban_supervisor.py` Ruff also reports the same 3 pre-existing errors on both, in files this PR does not touch. - `sh -n` clean on the Keycloak script. The repo has no shellcheck target and shellcheck is not installed in this image, so syntax checking is the available level of static verification there. - `gofmt -l` clean on the router, and the router still builds with the same `GO111MODULE=off` invocation the Dockerfile uses. Draft PR — not merging. Over to you.
hermes-automation added 1 commit 2026-08-20 22:18:52 +00:00
Rename two public Hermes hostnames across the repo:

  chat.hermes.bstein.dev   -> hermes.bstein.dev
  triage.hermes.bstein.dev -> triage.bstein.dev

agent.hermes.bstein.dev is left untouched. That rename ships separately and
must merge last, because it is the coordinator's own access point.

Covers CoreDNS host entries, the shared hermes-sites certificate SANs and
the ingress rules, Keycloak OIDC redirect/origin/post-logout URLs,
oauth2-proxy redirect URLs, CORS and allowed-origin settings, dashboard
public URLs, the Ariadne proposal UI link, ZAP baseline scan targets, the
operator and agent instruction text, the Telegram sign-in prompts, and the
Docker/UI references.

Knowledge catalogs and the HTTP diagram were regenerated with
scripts/render/knowledge_render_atlas.py rather than hand-edited. Only the
rename delta is carried here: the committed catalogs on main are already
stale by roughly 1650 lines, and that drift is left for a separate cleanup.

Repo-only change. After merge it needs the Keycloak ensure script re-run and
certificate reissuance; existing oauth2-proxy sessions are invalidated.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Owner

Wrong hostnames

Wrong hostnames
bstein closed this pull request 2026-08-21 07:31:02 +00:00

Pull request closed

Sign in to join this conversation.
No Reviewers
No Label
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: titan/atlas-iac#28
No description provided.