Skip to content

[Feature][Grafana][config-ui] Gaps when running DevLake with a managed PostgreSQL and an external Grafana #9219

Open

Description

@DoDiODev

Search before asking

  • I had searched in the issues and found no similar feature requirement.

Use case

We run DevLake in Kubernetes with a managed PostgreSQL (TLS with a
corporate CA, sslmode=verify-full) and want to use a managed / external
Grafana
. Data sources are GitHub, GitLab, Jira and SonarQube.

The backend handles this setup fine (DB_URL is passed unchanged to pgx, so
sslmode=verify-full&sslrootcert=… works). The gaps are in the dashboard image
(grafana/scripts/entrypoint.sh) and in the config-ui. This issue collects
them in one place, so that the small PRs below can refer to it.

Description

Verified on main @ 4ad2f66df, PostgreSQL mode only. We do not run MySQL,
so MySQL paths are left unchanged and untested.

A. Dashboard image ↔ managed PostgreSQL over TLS (one small, additive PR planned)

  • DATABASE_SSL_MODE is read by entrypoint.sh (default disable), but
    docker-compose-dev-postgresql.yml / env.example do not pass it
    through (follow-up to build(compose): make grafana port, root URL and datasource configurable #9207). Proposal: GRAFANA_DATABASE_SSL_MODE
    → DATABASE_SSL_MODE, default disable.
  • The PostgreSQL datasource payload has no sslRootCertFile /
    sslCertFile / sslKeyFile, so verify-ca / verify-full against a
    private CA fails. Proposal: optional DATABASE_SSL_ROOT_CERT
    (+ _CERT / _KEY) → jsonData.tlsConfigurationMethod: "file-path".
  • The API calls use a hard-coded admin: user. Renaming the admin via
    GF_SECURITY_ADMIN_USER silently breaks datasource creation, because
    the POST status is not checked. Proposal: ${GF_SECURITY_ADMIN_USER:-admin}
    plus a status check with a log message.
  • The entrypoint deletes all datasources on every start ("clean
    slate"). This is destructive when the Grafana state is shared (GF_DATABASE_*,
    several replicas, manually added datasources). Proposal for the PR: an
    opt-out DATASOURCE_CLEAN_SLATE=false. The default stays true, so
    the current behaviour is unchanged.

B. config-ui ↔ Grafana links (one small bug-fix PR planned)

  • With USE_EXTERNAL_GRAFANA=true, nginx.conf returns
    302 "${GRAFANA_ENDPOINT}" and drops the path and query, so every
    /grafana/d/<uid>/… deep link lands on the Grafana home page. Proposal:
    append the remaining path + $is_args$args.
  • Onboarding "Check Dashboard" (GitHub / GitLab,
    routes/onboard/step-4.tsx, components/card.tsx) calls
    window.open(import.meta.env.DEVLAKE_DASHBOARD_URL_*). The released
    image is built without a .env and the code has no fallback, so the
    button opens an empty tab. The example values in config-ui/env.example
    point to the MySQL UIDs (KXWvOFQnz, msSjEq97z), while the PostgreSQL
    dashboards use …-pg. Proposal: a DB-independent fallback (e.g.
    /grafana/dashboards?query=GitHub), or hide the button when the
    variable is empty. Also document the PostgreSQL UIDs.

C. Open points, no PR planned for now (feedback welcome)

  • Clean slate, alternatives to the opt-out: (i) delete only the DevLake
    datasource (UID devlake-postgres-api / devlake-mysql-api), or
    (iii) switch to file provisioning with env interpolation instead of the
    API.
  • Root-level dashboards ClaudeCodeAdoption*.json, Incidentio.json,
    Linear.json and Rootly.json reference the MySQL datasource
    devlake-mysql-api, but are also shipped in PostgreSQL mode, where they
    show datasource errors. Moving them to dashboards/mysql/ (plus
    PostgreSQL variants), and adding a dashboard-check rule against files
    directly under dashboards/, would fix this.
  • DEVLAKE_GRAFANA_PATH / DEVLAKE_DASHBOARD_URL_* are build-time only
    (Vite envPrefix). With relative /grafana/… links and the redirect
    fix from B this is fine for us. Runtime configuration (e.g. an
    env-config.js generated by nginx.sh) would only matter for setups
    with different dashboard UIDs or a non-default Grafana org. Noted here
    for completeness.

Related issues

Are you willing to submit a PR?

  • Yes I am willing to submit a PR!

I will open the PRs for A and B one after another and link them here. They
are small and additive, and the defaults are unchanged.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions