Commit Graph

17 Commits

Author SHA1 Message Date
Maximilian Bosch
8511063014
grafana: 11.0.0 -> 11.1.0
ChangeLog: https://github.com/grafana/grafana/releases/tag/v11.1.0

A few additional changes were necessary:

* Grafana now refuses to listen on non-IP values and aborts with

    Error: ✗ *apiserver.service run error: invalid IP address: localhost

* packages/grafana-e2e doesn't exist anymore, so the build fixes for
  that could be removed.

* Make sure we always compile the binary parts of cypress.

* Grafana tends to set the minimum Go version to the latest Go version
  available now[1].

* The `url` of a datasource was set to `localhost` by default. I don't
  expect anybody to have not set it when needed, also Grafana aborts now
  if `url` is non-empty for a random walk datasource (which broke the VM
  tests).

[1] https://github.com/grafana/grafana/pull/88794#discussion_r1630563467
2024-06-29 19:09:05 +02:00
Maximilian Bosch
0118cc1d67
grafana: 10.4.2 -> 11.0.0
Announcement: https://grafana.com/docs/grafana/latest/whatsnew/whats-new-in-v11-0/
ChangeLogs:
* https://github.com/grafana/grafana/releases/tag/v11.0.0
* https://github.com/grafana/grafana/blob/v11.0.0/CHANGELOG.md#1100-preview

Legacy notifiers were removed and could thus be removed from the module.
2024-05-14 19:03:25 +02:00
Maximilian Bosch
48459567ae nixos/postgresql: drop ensurePermissions, fix ensureUsers for postgresql15
Closes #216989

First of all, a bit of context: in PostgreSQL, newly created users don't
have the CREATE privilege on the public schema of a database even with
`ALL PRIVILEGES` granted via `ensurePermissions` which is how most of
the DB users are currently set up "declaratively"[1]. This means e.g. a
freshly deployed Nextcloud service will break early because Nextcloud
itself cannot CREATE any tables in the public schema anymore.

The other issue here is that `ensurePermissions` is a mere hack. It's
effectively a mixture of SQL code (e.g. `DATABASE foo` is relying on how
a value is substituted in a query. You'd have to parse a subset of SQL
to actually know which object are permissions granted to for a user).

After analyzing the existing modules I realized that in every case with
a single exception[2] the UNIX system user is equal to the db user is
equal to the db name and I don't see a compelling reason why people
would change that in 99% of the cases. In fact, some modules would even
break if you'd change that because the declarations of the system user &
the db user are mixed up[3].

So I decided to go with something new which restricts the ways to use
`ensure*` options rather than expanding those[4]. Effectively this means
that

* The DB user _must_ be equal to the DB name.
* Permissions are granted via `ensureDBOwnerhip` for an attribute-set in
  `ensureUsers`. That way, the user is actually the owner and can
  perform `CREATE`.
* For such a postgres user, a database must be declared in
  `ensureDatabases`.

For anything else, a custom state management should be implemented. This
can either be `initialScript`, doing it manual, outside of the module or
by implementing proper state management for postgresql[5], but the
current state of `ensure*` isn't even declarative, but a convergent tool
which is what Nix actually claims to _not_ do.

Regarding existing setups: there are effectively two options:

* Leave everything as-is (assuming that system user == db user == db
  name): then the DB user will automatically become the DB owner and
  everything else stays the same.

* Drop the `createDatabase = true;` declarations: nothing will change
  because a removal of `ensure*` statements is ignored, so it doesn't
  matter at all whether this option is kept after the first deploy (and
  later on you'd usually restore from backups anyways).

  The DB user isn't the owner of the DB then, but for an existing setup
  this is irrelevant because CREATE on the public schema isn't revoked
  from existing users (only not granted for new users).

[1] not really declarative though because removals of these statements
    are simply ignored for instance: https://github.com/NixOS/nixpkgs/issues/206467
[2] `services.invidious`: I removed the `ensure*` part temporarily
    because it IMHO falls into the category "manage the state on your
    own" (see the commit message). See also
    https://github.com/NixOS/nixpkgs/pull/265857
[3] e.g. roundcube had `"DATABASE ${cfg.database.username}" = "ALL PRIVILEGES";`
[4] As opposed to other changes that are considered a potential fix, but
    also add more things like collation for DBs or passwords that are
    _never_ touched again when changing those.
[5] As suggested in e.g. https://github.com/NixOS/nixpkgs/issues/206467
2023-11-13 17:16:25 +01:00
nikstur
da274a11d7 nixos/tests/grafana: replace activationScript with tmpfiles 2023-10-26 01:44:21 +02:00
Maximilian Bosch
859f4aa172
nixos/tests/grafana/provision: fix test
Not sure why the tmpfile rule fails now, so let's quick-fix it with an
activation script.
2023-01-29 16:50:56 +01:00
Franz Pletz
a0b6072547
nixos/grafana: add test case for socket proxy 2022-12-14 14:42:13 +01:00
Maximilian Bosch
9d7e9c5965
nixos/grafana: allow using both directories or single YAML files for non-Nix provisioning 2022-11-20 18:21:41 +01:00
Maximilian Bosch
febc8a4307
nixos/tests/grafana: demonstrate how to use the file provider
Yes, it's still a store path, but it's only for demonstration purposes.
Also we now have fewer warnings in the provision test.
2022-11-20 18:21:40 +01:00
Maximilian Bosch
afd6199cff
nixos/grafana: re-add legacy notifiers test, mention notifiers in release notes 2022-11-20 18:21:39 +01:00
Maximilian Bosch
957e368f3d
nixos/grafana: provision.{datasources,dashboards} can't be a list anymore
The hack with `either` had the side-effect that the sub-options of the
submodule didn't appear in the manual. I decided to remove this because
the "migration" isn't that hard, you just need to fix some module
declarations.

However, `mkRenamedOptionModule` wouldn't work here because it'd create
a "virtual" option for the deprecated path (i.e.
`services.grafana.provision.{datasources,dashboards}`), but that's the
already a new option, i.e. the submodule for the new stuff.

To make sure that you still get errors, I implemented a small hack using
`coercedTo` which throws an error if a list is specified (as it would be
done on 22.05) which explains what to do instead to make the migration
easier.

Also, I linkified the options in the manual now to make it easier to
navigate between those.
2022-11-20 18:21:35 +01:00
KFears
f3cb29a5b8 nixos/grafana: fix issues with rfc42 refactoring 2022-10-24 19:31:50 +04:00
Maximilian Bosch
dfdff2b946
nixos/tests/grafana: remove superfluous args@ 2022-10-23 13:08:45 +02:00
KFears
5ea8f47014 nixos/grafana: write more efficient tests 2022-10-22 23:56:15 +04:00
KFears
7908ef062f nixos/grafana: add alerting 2022-10-22 23:54:32 +04:00
KFears
34c2ea6750 nixos/grafana: deprecate notifiers 2022-10-22 23:54:31 +04:00
KFears
0852dc859e nixos/grafana: refactor datasources for RFC42
This commit refactors `services.grafana.provision.datasources` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
2022-10-22 23:53:24 +04:00
KFears
89e30315e0 nixos/grafana: refactor dashboards for RFC42
This commit refactors `services.grafana.provision.dashboards` towards
the RFC42 style. To preserve backwards compatibility, we have to jump
through a ton of hoops, introducing esoteric type signatures and bizarre
structs. The Grafana module definition should hopefully become a lot
cleaner after a release cycle or two once the old configuration style is
completely deprecated.
2022-10-21 16:42:30 +04:00