The built-in "-- Grafana --" datasource has no row in the datasource table,
so legacyConnectionClientImpl.GetConnectionByUID could never resolve its plugin
type. For RBAC roles carrying the seeded datasources:uid:grafana grant this was
silently unresolved, and for global roles (orgID 0, multi-org) the store lookup
failed with ErrDataSourceIdentifierNotSet, breaking role provisioning.
Its UID and type are fixed and identical across orgs, so resolve it directly in
the legacy connection client. This fixes datasource-type resolution for every
caller that goes through this client (provisioning save and the k8s migration
type resolvers) without a store row.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
* Health API: integrate apiserver readiness into /api/health
The /api/health endpoint is used as the Kubernetes readiness probe for
ST Grafana. Previously it only checked database connectivity, so
Kubernetes would route traffic before the apiserver's boot sequence
completed — causing 503s for aggregated API requests during the brief
window where serviceAvailable=false in proxy handlers.
When the apiserver's clientConfigProvider is available, /api/health now
makes an internal call to /readyz via DirectlyServeHTTP. If /readyz
returns non-200 (boot sequence health checks haven't passed), /api/health
returns 503 with "apiserver": "not ready" in the response body.
This eliminates user-facing 503s during pod startup without requiring
changes to deployment manifests (readiness probe stays on /api/health).
Stress test results (mt-tilt, 5 replicas scaling up simultaneously):
- 1240 requests during scale-up, zero 503s
When clientConfigProvider is nil (no apiserver, OSS without aggregation,
or unit tests), the check is skipped — no behavior change.
Companion to grafana-enterprise#11254 which adds the
remote-apiservice-initialization boot sequence health check.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Health API: use timeout for apiserver readiness check
DirectlyServeHTTP blocks until the apiserver is ready. Without a
timeout, the health check would hang during startup (or in tests where
the apiserver hasn't started). Use a 2-second context timeout so the
health check returns "not ready" promptly instead of blocking.
Also check for context timeout explicitly — httptest.NewRecorder
defaults to status 200 if no response is written, which would
incorrectly pass the readiness check on timeout.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Health API: integrate apiserver readiness into /api/health
The /api/health endpoint is used as the Kubernetes readiness probe for
ST Grafana. Previously it only checked database connectivity, so
Kubernetes would route traffic before the apiserver's boot sequence
completed — causing 503s for aggregated API requests during the brief
window where serviceAvailable=false in proxy handlers.
Add IsReady() to the DirectRestConfigProvider interface. The
eventualRestConfigProvider implements it with a non-blocking select on
the ready channel — returns true immediately once the apiserver has
started, false otherwise.
When the apiserver is not ready, /api/health returns 503 with
"apiserver": "not ready" in the response body. When clientConfigProvider
is nil (no apiserver, or unit tests), the check is skipped.
Stress test results (mt-tilt, 5 replicas scaling up simultaneously):
- 1240 requests during scale-up, zero 503s
Companion to grafana-enterprise#11254 which adds the
remote-apiservice-initialization boot sequence health check.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* make gofmt
* fix
* regenerate health response with apiserver key
* make gen-apps
* fix
* remaining gen-apps
* lint
* gofmt
* trigger build
* fix
* fix
* fix
* lint frontend
---------
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* add some integration tests for existing datasource crud endpoints
* implement GET by uid redirect handler
* fix apis authorizer
* add unit tests for connections client
* add tests for the k8s datasource handler
* use the correct group, and dont prettify group name in listConnections response
* Moving things around
* Copy parseURL function to where it's used
* Update test
* Remove experimental-strip-types
* Revert "Remove experimental-strip-types"
This reverts commit 70fbc1c0cd.
* Trigger build
* wip
* Add prom flavor support for data source variables and export/import dashboards (#103321)
* add dashboard and data source var selection
* use match plugin id instead
* use updated matchpluginid
* formatting
* cleanup
* regex anchor
* update error msg
* Alerting: Clean up prometheus-flavored types and functions (#103703)
* clean up types and utility functions for dealing with
prometheus-flavored data sources
* Refactor alerting datasource types to use constants as source of truth
* Alerting: Clean up prometheus-flavored types and functions on the bac… (#103716)
Alerting: Clean up prometheus-flavored types and functions on the backend
* add matchPluginId tests
* Update matchPluginId func to bidirectional (#103746)
* update matchpluginid func to bidirectional
* lint
* formatting
* use actual isSupportedExternalRulesSourceType in test
* add tests in datasource_srv
* betterer
* remove type assertion
* remove unnecessary case
* use satisifies to not have to convert tuple to an array of string
* add prometheus_flavor test
---------
Co-authored-by: Andrew Hackmann <5140848+bossinc@users.noreply.github.com>
Co-authored-by: Gilles De Mey <gilles.de.mey@gmail.com>
Co-authored-by: Alexander Akhmetov <me@alx.cx>
* checks for empty URLs added
* check for TimeSeriesTypeNot to fix InfluxDB alerts
* log a warning when a data frame is ignored
* fix: add brittle Prometheus URL input selector
needs a proper aria-label or test-data-id selector
* test: add URL input aria-label
needs to use the grafana/e2e-selectors package
* test: run ci
* add URL validation for specific data sources, e2e tests
* Update pkg/api/datasource/validation.go
Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
* delete duplicated logs
* delete unnecessary leading newline
Co-authored-by: gillesdemey <gilles.de.mey@gmail.com>
Co-authored-by: Marcus Efraimsson <marcus.efraimsson@gmail.com>
