Skip to content
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

Merged
merged 1 commit into from Sep 7, 2018
Merged

Conversation

shmish111
Copy link
Contributor

@shmish111 shmish111 commented Aug 2, 2018

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
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Fits CONTRIBUTING.md.

Copy link
Member

@infinisil infinisil left a 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 {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Member

@infinisil infinisil Aug 15, 2018

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.

Copy link
Contributor Author

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?

Copy link
Member

@infinisil infinisil Aug 15, 2018

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 ];
Copy link
Member

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.

@shmish111
Copy link
Contributor Author

@infinisil configFiles is only suitable for basic deployments since it just uses load-file at the end of the configuration. You could in theory get things done like this but it doesn't allow you to set up a proper Clojure project to do complex development of riemann config. Riemann has a built in mechanism to allow this in that it will add all Clojure files in the directory of the config file onto the classpath. The current nix module solution of load-file is not really suitable, I've left it in here as it is workable and presumably some people are already doing that so we should maintain backward compatibility however it should not be the recommended solution. I am using my fork in production which enables me to setup my Riemann config as a leiningen project and just copy the source files across to the nix config.

@infinisil
Copy link
Member

Riemann has a built in mechanism to allow this in that it will add all Clojure files in the directory of the config file onto the classpath.

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 configFile instead of configDirectory and configFileName, since the only place you use these new options is to pass a single file to it ("${cfg.configDirectory}/${cfg.configFileName}"). Clojure would then automatically use dirname configFile as the directory.

@shmish111
Copy link
Contributor Author

@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.

@shmish111
Copy link
Contributor Author

ok @infinisil I've made those 2 changes and squashed things, I think it looks much better thanks. Ready for review again.

@shmish111
Copy link
Contributor Author

bump @infinisil

@@ -84,6 +100,8 @@ in {
User = "riemann";
ExecStart = "${launcher}/bin/riemann";
};
serviceConfig.LimitNOFILE = 65536;
restartTriggers = [ configFile ];
Copy link
Member

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}"
);
Copy link
Member

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}"
Copy link
Member

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)
Copy link
Member

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

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.
@shmish111
Copy link
Contributor Author

ok @infinisil I have made the suggested changes and tested it on my own nixos machine, works nicely

@infinisil infinisil merged commit 00c6f85 into NixOS:master Sep 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants