EC2 resources dependent on config.nodes.mynode.config.networking.privateIPv4 about nixops-aws

[danbst]

@coretemp you don't have to believe. Here is a module you can plugin and check yourself

   { lib, nodes, pkgs, ...}: {
        networking.hosts."${nodes.some-machine.config.networking.privateIPv4}" = [ "alias-machine" ];
   }

This is excerpt from my NixOps config

[danbst]

NixOps adds one more top-level argument nodes to each module args list, which you can inspect

{ config, pkgs, lib, nodes, ... }:
{
  ... nodes.mynode.config.networking.privateIPv4 ...
}

[coretemp]

@danbst I will believe that it works when I see a test in the nixops repository doing exactly what I described, because I have tried these things and it does not work.

I do use nodes as an argument in some places already, but this described a very specific interaction, which is likely a bug.

[AmineChikhaoui]

@coretemp I guess it depends on which EC2 resource are you assigning this option to. If it's a NixOS machine configuration, I think it will likely work. Otherwise, for non machine resources (security groups etc ) I don't think the config is evaluated when the resource evaluation is done, so the IP address is undefined at that time. Do you have some concrete examples of the use case you're trying ?

[coretemp]

@AmineChikhaoui Yes, this is about non-machine resources.

# this is the network configuration (as per NixOps manual)
{arguments}:
let 
   machine1 = <snip>;
   machine2 = <snip>;
in
{ 
 <other resources>;
    resources.ec2SecurityGroups.mysecuritygroup = {
      inherit accessKeyId region;
      description = "a";
      rules = [
      { protocol = "tcp"; fromPort = 0; toPort = 65535;
        sourceIp = "${nodes.machine2.config.networking.privateIPv4}/32"; 
      }
        ];
    };
}

[AmineChikhaoui]

@coretemp yeah unfortunately I don't think there is a way to do that at the moment.

[coretemp]

If there is nothing in the manual allowing this behavior (I don't think there is), it should be labeled as a bug.

[picnoir]

All rudeness aside, I've been investigating on that a bit.

The problem comes from here: https://github.com/NixOS/nixops/blob/master/nix/eval-machine-info.nix#L82

Instead of forwarding the nodes attrset (see https://github.com/NixOS/nixops/blob/master/nix/eval-machine-info.nix#L35 ), info.machines is forwarded.

I guess we could add a nodes.nodes attribute forwarding the actual nodes attrset in order to not break any backward compatibility.

@rbvermaa Is there a particular reason to forward info.machines here?

[tewfik-ghariani]

Anyone has any idea how this can be accomplished?

[tewfik-ghariani]

Actually, I was able to proceed with a workaround consisting in whitelisting the whole VPC CIDR Block and it worked just fine for me in case anyone else is interested.