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.

Sign up for GitHub

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

Jump to bottom

[WIP] One way to do other types of services #26075

Closed
wants to merge 1 commit into from
Closed

[WIP] One way to do other types of services #26075

wants to merge 1 commit into from

Conversation

copumpkin
Copy link
Member

Motivation for this change

See #26067. Not quite sure how to expose this, and I'd be tempted to move the service modules out of the nixos folder if this catches on.

Here's how I use it:

(import ./nixos/lib/eval-config.nix {
  modules = [
    {
      services.hologram-server = {
        enable = true;
        awsAccount = "123456";
        awsDefaultRole = "foo";
        ldapBaseDN = "foobar";
        ldapBindDN = "baaz";
        ldapBindPassword = "quuux";
        ldapHost = "zomg";
      };
    }
  ];
}).config.system.build.toplevel-trivial

Then just nix-build that and you get a runner script that launches your service on any platform supported by the package.

Also, toplevel-docker will contain as many dockerTools-style containers as your config has docker-flavored services enabled.

@mention-bot
Copy link

@copumpkin, thanks for your PR! By analyzing the history of the files in this pull request, we identified @edolstra, @bjornfor and @offlinehacker to be potential reviewers.

@copumpkin copumpkin mentioned this pull request May 25, 2017
Open
copumpkin
copumpkin commented May 25, 2017
View reviewed changes
nixos/modules/services/security/hologram-server.nix
inherit script;
};

docker-containers.hologram-server = {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could probably abstract many basic simple services like this with a simple function to automatically do docker-containers, trivial-services, and maybe even systemd.services. The autogenerated config could then be merged with idiosyncratic config for any of those.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if we should put those options into the top-level but I love the basic idea!

Mic92
Mic92 reviewed May 25, 2017
View reviewed changes
nixos/modules/services/security/hologram-server.nix
serviceConfig = {
ExecStart = "${pkgs.hologram.bin}/bin/hologram-server --debug --conf ${cfgFile}";
};
inherit script;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would keep serviceConfig.ExecStart = script; as direct commands are more transparent to the user (ex: there are visible in systemctl status). Otherwise the user has to look at the content of the script file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For my launchd modules I added command which defaults to a writeScript if a script is defined.

@copumpkin
Copy link
Member Author

My main question for feedback is how do we expose this sort of thing? I was thinking of something like the following:

{
  dockerServices = config: (import ./nixos/lib/eval-config.nix {
    modules = [ config ];
  }).config.system.build.toplevel-docker;
}

But it feels a bit awkward to then stick dockerServices in all-packages.nix. I really just want to be able to call a function, pass in some service config, and get out a nice baked container image (or several). Same with trivialServices for simple shell launchers.

I imagine nix-darwin would consume it differently.

Another question is how to warn people if they decide to specify useless config in there. Someone could write networking.firewall.enable = true inside the config block they pass to dockerServices but it would just be ignored. I'd rather the user be warned not to use irrelevant config. I could do as @edolstra said in the other ticket and only selectively include modules based on some meta tag, but I liked the laziness of not doing that.

copumpkin added a commit that referenced this pull request Oct 13, 2017
@copumpkin
Revert "Simple proof of concept for how to do other types of services"
56e18c5 
This reverts commit 7c3253e.

I included this in another push by accident and never intended for it to
be in mainline. See #26075 if you
want more.
@copumpkin copumpkin mentioned this pull request Dec 22, 2017
Closed
@benley benley mentioned this pull request Feb 4, 2019
Merged
8 tasks
@mmahut
Copy link
Member

mmahut commented Aug 3, 2019

What is the status of this pull request?

@mmahut
Copy link
Member

mmahut commented Oct 5, 2019

Closing due to lack of activity, feel free re-open this if needed.

@mmahut mmahut closed this Oct 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@Mic92 Mic92 Mic92 left review comments

@fpletz fpletz fpletz left review comments

@LnL7 LnL7 LnL7 left review comments

Assignees
No one assigned
Labels
2.status: work-in-progress 9.needs: community feedback
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
7 participants
@copumpkin @mention-bot @mmahut @Mic92 @fpletz @LnL7 @matthewbauer