Prometheus: upgrade configuration module to use the 2.x package #46069
Conversation
|
I've thought about this a lot in the past. I don't think it's a good idea to update prometheus to 2.x quietly because old data won't be available anymore as you've already mentioned. On the other hand I agree that we have to update to 2.x as soon as possible. Also, some options slightly changed but we've already made these changes in our fork (we've got a dedicated If we do this like you propose, we would have to at least mention this change in the release notes because it is a backwards-incompatible change. @vcunat & @samueldr What do you think about this change for 18.09? Do you think that adding a new |
|
I would also favor a |
|
If this is about DB data, have you considered using |
|
@vcunat can you elaborate please? |
|
I think what @vcunat mean it to just make it depend on I actually also thought about making it depend on |
Fix flightgear, simgear & speed_dreams
ntp: fix ntpd shutdown by using upstream patch
brlaser: fix install dir
webkitgtk: 2.22.2 -> 2.22.3
c-ares: 1.14.0 -> 1.15.0
activation-script: add libc to path to provide nscd when needed
z3: 4.7.1 -> 4.8.1
thunderbolt: cleanup
nim: 0.18.0 -> 0.19.0
As reported by @andir, the regular expressions that match the sandbox output are no longer matching in the recent Chromium bump as of bb03fbc. Instead of a boolean field that determines whether namespace sandboxes are on, the namespace sandbox is now an enum within "Layer 1 Sandbox". I've modified the regular expressions accordingly and also ran the test for the stable branch, which now succeeds. Signed-off-by: aszlig <aszlig@nix.build> Issue: NixOS#49442 Cc: @bendlas, @andir
nixos/syncthing: move configuration to condigDir
azazel75
requested review from
rycee,
thoughtpolice,
ttuegel and
zimbatm
as code owners
|
So, now that I've completed the merge: I spent the time of running the two in parallel because it seemed to me that this was the idea of most of the people that wrote here. Now that I've done this it seems that the idea has changed to trash the old 1.x service and keep the 2.x. Maybe you guys should come to an agreement ;-) |
|
Uhumm, it seems I've made some serious errors in this branch while trying to rebasing it, I'm sorry. I'll try to fix it |
|
I would keep both modules for the next release (to be able to run them in parallel for one release), but with actually having copied the previous module (with intended code duplication). This will make it easier to just remove prometheus(1) after the next release and not having to disentangle them again by hand. |
Mic92
removed request for
zimbatm,
thoughtpolice,
ryantm,
matthewbauer,
peti,
edwtjo,
Mic92,
fpletz,
ttuegel,
basvandijk,
LnL7,
rycee,
Ericson2314,
edolstra,
nbp,
FRidh and
Profpatsch
|
Please see #49802 |
|
mind if we close this PR since it looks like we're continuing over in the other one now? |
Although it's not possible to migrate an existing 1.x to 2.x this upgrade seems appropriate because there are no more 1.x docs available online and the configuration format changed without backward compatibility letting people installing it having serious issues.
This upgrade is conservative: it keeps all the old configuation items without introducing new ones that may be preferable to configure "alertmanager service discovery" optional feature. (It's possible to configure it specifying a configuration file)
I've personally spent some ours finding out that the configuration error reported by the prometheus daemon on my installation was really a misconfiguration due to the use of the old prometheus 1.x by the configuration module, despite the fact that the prometheus 2.x it's already available in nixpackages.
Motivation for this change
Configure a version of the prometheus services that you can actually find documentation for.
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)