-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nixos/riemann: refactor config #44341
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure the config file options you added can simply be done through the configFiles
option, they're not needed.
@@ -64,6 +93,12 @@ in { | |||
Extra Java options used when launching Riemann. | |||
''; | |||
}; | |||
environment = mkOption { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users can just set systemd.services.riemann.environment
directly in their NixOS config, will work just as expected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy to take this out, just wasn't sure which was the more nixy way of doing things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the reason I ask this is because I am using this as:
services.riemann = {
enable = true;
environment = { RIEMANN_HOME = riemannConfigDir; };
configDirectory = riemannConfigDir;
};
and it would not look so nice to me if the environment
line was outside of the definition of services.riemann
. What do you think @infinisil @joachifm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think options for services should provide something more powerful than just an alias for another options. But I see your point, the config would be all neat and together.
Eventually I think a better solution to that is to provide a generic service option to be used to get to a services systemd service like this:
services.riemann = {
enable = true;
service.environment = { RIEMANN_HOME = riemannConfigDir; };
configDirectory = riemannConfigDir;
}
This should probably then be a major nixpkgs change to implement it uniformly.
For now I think using
systemd.services.riemann.environment.RIEMANN_HOME = riemannConfigDir; };
should be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I like the sounds of that. However in the short term, do you want me to change this or leave it as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not have this (the new environment option).
serviceConfig = { | ||
User = "riemann"; | ||
ExecStart = "${launcher}/bin/riemann"; | ||
}; | ||
serviceConfig.LimitNOFILE = 65536; | ||
restartTriggers = [ configFile ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 2 lines are the only ones I can agree with right now.
@infinisil |
Okay that's an argument, there's no other way to achieve this? No direct argument to pass for adding stuff to the classpath? Doing it via this configDir/configFile way seems a bit ugly. Also, if we keep this, you can just use a single option for |
@infinisil I think it's fine to change to a single file and implicitly look in the directory that contains that file, I'll test it out. Personally I think that adding all files explicitly is much uglier, I want to have a source directory and provide that to the config (plus the name of the main config file). Also, constructing a config file in nix is not very nice, Riemann config is not like 'config' in other context, it is a full application, 'config' is perhaps a bad name for it. |
d383c7f
to
0e5d60d
Compare
ok @infinisil I've made those 2 changes and squashed things, I think it looks much better thanks. Ready for review again. |
bump @infinisil |
@@ -84,6 +100,8 @@ in { | |||
User = "riemann"; | |||
ExecStart = "${launcher}/bin/riemann"; | |||
}; | |||
serviceConfig.LimitNOFILE = 65536; | |||
restartTriggers = [ configFile ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the launcher will change every time the config file changes, there's no need to add it to the restart triggers manually.
cfg.configFile | ||
else | ||
"${writeText "riemann-config.clj" riemannConfig}" | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary parens
then | ||
cfg.configFile | ||
else | ||
"${writeText "riemann-config.clj" riemannConfig}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unnecessary "${..}"
@@ -15,11 +15,18 @@ let | |||
[cfg.config] ++ (map (f: ''(load-file "${f}")'') cfg.configFiles) | |||
); | |||
|
|||
configFile = (if (cfg.configFile != null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll also suggest a cleaner alternative of implementing this:
{
# ...
config = mkIf cfg.enable {
services.riemann.configFile = mkDefault (
writeText "riemann-config.clj" riemannConfig
);
};
}
And then use cfg.configFile
in the launcher.
The module system will then automatically take care of making a user-specified configFile a priority. This also has the advantage that the user can see the generated config file via nix-instantiate --eval '<nixpkgs/nixos>' -A config.services.riemann.configFile
0e5d60d
to
7f76719
Compare
Previously it was only possible to use very simple Riemann config. For more complicated scenarios you need a directory of clojure files and the config file that riemann starts with should be in this directory.
9c276eb
to
1d497bb
Compare
ok @infinisil I have made the suggested changes and tested it on my own nixos machine, works nicely |
Previously it was only possible to use very simple Riemann config.
For more complicated scenarios you need a directory of clojure
files and the config file that riemann starts with should be in this
directory.
Motivation for this change
I needed a more complex Riemann setup in my NixOS project.
Things done
sandbox
innix.conf
on non-NixOS)nix-shell -p nox --run "nox-review wip"
./result/bin/
)nix path-info -S
before and after)