grafana: its directories are placed, its admin password is a file, and it runs the build in use #153

2026-09-29T22:12:32Z

mesh-admin commented

2026-09-29 22:12:32 +00:00

The module stated /var/lib/grafana-module and /services/grafana/data, a
layout no definition may carry (ADR 0112). State and data are now placed
directories; the admin secret lives beside the broker account under the
mesh's own state.

The admin password reached grafana through an env-file. Grafana honours
GF_SECURITY_ADMIN_PASSWORD__FILE, so it is now a 0400 file owned by the
image's user (472) and mounted, and "secrets-in-environment" is gone
(ADR 0086).

The runtime sidecar was given no credential at all - its config file was
"{}", so GrafanaClient.fromEnv threw and the tools and the alert watcher
did nothing. It now carries user/password from the same secret, and it
calls grafana on the machine port the mesh assigned (${port:3000}) rather
than a literal 3000.

Image pinned to the 13.2.2 build ace's predecessor runs; the old pin was
13.2.1, older than the data it would open.

Verified: catalogue tests with MESH_CATALOGUE pointing here; a throwaway
container of the pinned image with the file-mounted secret answers
/api/health and authenticates admin with the file's value (default
admin/admin refused); restarted over the same data with a different file
value, the original password still holds - so a migrated instance's
password must be accepted, not minted; data owned by another uid fails to
start, so a moved data directory must be chowned to 472.

The module stated /var/lib/grafana-module and /services/grafana/data, a layout no definition may carry (ADR 0112). State and data are now placed directories; the admin secret lives beside the broker account under the mesh's own state. The admin password reached grafana through an env-file. Grafana honours GF_SECURITY_ADMIN_PASSWORD__FILE, so it is now a 0400 file owned by the image's user (472) and mounted, and "secrets-in-environment" is gone (ADR 0086). The runtime sidecar was given no credential at all - its config file was "{}", so GrafanaClient.fromEnv threw and the tools and the alert watcher did nothing. It now carries user/password from the same secret, and it calls grafana on the machine port the mesh assigned (${port:3000}) rather than a literal 3000. Image pinned to the 13.2.2 build ace's predecessor runs; the old pin was 13.2.1, older than the data it would open. Verified: catalogue tests with MESH_CATALOGUE pointing here; a throwaway container of the pinned image with the file-mounted secret answers /api/health and authenticates admin with the file's value (default admin/admin refused); restarted over the same data with a different file value, the original password still holds - so a migrated instance's password must be accepted, not minted; data owned by another uid fails to start, so a moved data directory must be chowned to 472.

mesh-admin added 1 commit 2026-09-29 22:12:33 +00:00

grafana: its directories are placed, its admin password is a file, and it runs the build in use a5e21cb438

The module stated /var/lib/grafana-module and /services/grafana/data, a
layout no definition may carry (ADR 0112). State and data are now placed
directories; the admin secret lives beside the broker account under the
mesh's own state.

The admin password reached grafana through an env-file. Grafana honours
GF_SECURITY_ADMIN_PASSWORD__FILE, so it is now a 0400 file owned by the
image's user (472) and mounted, and "secrets-in-environment" is gone
(ADR 0086).

The runtime sidecar was given no credential at all - its config file was
"{}", so GrafanaClient.fromEnv threw and the tools and the alert watcher
did nothing. It now carries user/password from the same secret, and it
calls grafana on the machine port the mesh assigned (${port:3000}) rather
than a literal 3000.

Image pinned to the 13.2.2 build ace's predecessor runs; the old pin was
13.2.1, older than the data it would open.

Verified: catalogue tests with MESH_CATALOGUE pointing here; a throwaway
container of the pinned image with the file-mounted secret answers
/api/health and authenticates admin with the file's value (default
admin/admin refused); restarted over the same data with a different file
value, the original password still holds - so a migrated instance's
password must be accepted, not minted; data owned by another uid fails to
start, so a moved data directory must be chowned to 472.

mesh-admin referenced this pull request

2026-09-29 22:39:57 +00:00

oidc-client: keycloak makes each consumer its client; grafana logs in through it #155

mesh-admin referenced this pull request

2026-09-29 22:49:10 +00:00

oidc-client: keycloak makes each consumer its client; grafana logs in through it #155

You are not authorized to merge this pull request.

This pull request can be merged automatically.

This branch is out-of-date with the base branch

View command line instructions