Fully modular

[shlevy]

This branch is an attempt at solving #78. It (shouldn't) change any functionality at all yet, so it can go into master, though we can merge it into next as well. If/when we decide this is OK to merge I'll do the actual merge to avoid conflicts.

Note that currently there's no way to actually pass network-level modules to nixops yet. Adding that functionality will be trivial now that this is in place, but there are some interface/backwards-compatibility decisions to be made there that are orthogonal to using network-level modules internally.

This depends on NixOS/nixpkgs#598 or something equivalent.

[edolstra]

What are "old-style networks"?

[shlevy]

The network expressions we currently use

[edolstra]

Okay, I should have asked: what are "new-style networks".

[shlevy]

Well currently they are only an internal implementation detail, though the point of this whole exercise is to eventually make them the normal way of specifying a network. Instead of the way we currently write them, they'd be modules like:

{ config, lib, ... }:

let
  resources = config.resources;
in {
  require = [ ./logical-module.nix ];

  resources.machines.machine = { pkgs, config }: {
    deployment.ec2.keyPair = resources.ec2KeyPairs."build-machine-provisioner-keypair".name;
  };
  resources.ec2KeyPairs.build-machine-provisioner-keypair = {
    region = "us-east-1";
  };
}

IOW, new-style networks are just modules that are evaluated with the base.nix module included in the evaluation.

[rbvermaa]

Btw, config would be a terrible name for the network configuration...

[shlevy]

What do you mean? The config argument to the module?

[edolstra]

Yeah, all these config arguments might get a bit confusing. That's already the case with submodules...

[shlevy]

Hmm OK. that's just the name used internally by the module system, we can alias it.

[shlevy]

@edolstra If I bring this up-to-date and change the name from config, can we consider merging it?

[shlevy]

@edolstra ping?

[rbvermaa]

Did you change the config argument name already? If so, to what?

[shlevy]

No, it will take some work to update this to master and I wasn't sure if there was interest in having this merged. As for what to change it to, I'm open for suggestions but was thinking subconfig or resourceConfig (or machineConfig/queueConfig/etc.)

[rbvermaa]

I would leave config for machines, as that is the same as in NixOS. However, how about renamin the config at network level to network?

[shlevy]

Sure, that works too.

[shlevy]

@edolstra So is there interest in me updating this PR or should I close it?

[shlevy]

This PR depends on NixOS/nixpkgs@8179bad I've updated #78, which this PR is a part of, to describe a bit what the benefits are. Note that this PR doesn't actually change any external behavior, it just sets up the scaffolding necessary for #78 to be doable and uses that scaffolding internally.

[aszlig]

+1 on this. Though the problem I guess is that the mentioned nixpkgs dependency is quite new and thus will break with deployments using older nixpkgs. On the other side, people who want to switch over to new-style networks probably use newer nixpkgs, no?

[shlevy]

Closed in favor of #187