EC2 resources dependent on config.nodes.mynode.config.networking.privateIPv4

[coretemp]

I would like to define an EC2 resource, which depends on the IP address of a machine being deployed. I.e. config.nodes.mynode.config.networking.privateIPv4. Is that impossible or if not how can that be done?

The manual only contains overly simple examples where there is no interaction between the nodes being deployed and for example the security groups that should apply to it.

The use case is that I want two nodes to be able to talk to each other, but not to anything else.

[Danylo Hlynskyi]

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.

[Amine Chikhaoui]

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

[Danylo Hlynskyi]

@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

[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"; 
      }
        ];
    };
}

[Amine Chikhaoui]

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

[Félix]

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.