Expose resources to deployment.keys

[tomberek]

Re-evaluate info.machines in order to expose resources and publicIPv4 to deployment.keys.
Addresses #959

There may be a better way to do this, this is merely the first thing I was able to make work. Some defensive programming is needed due to the duplication evaluation, so something like this:

my_ip = let
     net = nodes.my-machine.config.networking;
     res = builtins.tryEval (
     if net.publicIPv4 != null then net.publicIPv4 else
     if net.privateIPv4 != null then net.privateIPv4 else "");
   in
    if res.success then res.value else "error";
...
deployment.keys."ip".text = my_ip;

[singron]

Is there anything blocking this? I ran into this issue and it would be nice to have a solution.

[dsg22]

I have a similar problem with commandOutput resources not being available during the initial deployment. Sadly, this patch does not make them available.

In the longer term I think we need a more complete solution to these issues (shouldn't these resources be evaluated lazily?). This patch might be an interim partial solution until then.

[RaitoBezarius]

Heads up, can we do anything to help core contributors to merge this or @tomberek can we help you to clean it?

[tomberek]

This change is fairly simple, but probably could be done cleaner or in a way that doesn’t require the tryEval construct. Or it’s done for the user behind the scenes.

[AmineChikhaoui]

I'm still not sure it would be a good idea to have 3 evals now, 2 evals is already slow and expensive depending on the number of machines in the network.

@edolstra btw would nix flakes make any of this better ? I hear there would be eval caching but also I'm not up to speed with the flakes branch of nixops maybe it makes some things better ?

[tomberek]

I agree that the implementation isn’t ideal, I just don’t know if of an alternative. Consider this implementation just a PoC to test if the feature is desirable/useful.

[grahamc]

Hello!

Thank you for this PR.

In the past several months, some major changes have taken place in
NixOps:

1. Backends have been removed, preferring a plugin-based architecture.
   Here are some of them:

   • https://github.com/NixOS/nixops-aws
   • https://github.com/NixOS/nixops-hetzner
   • https://github.com/nix-community/nixops-vbox
   • https://github.com/nix-community/nixops-libvirtd
   • https://github.com/nix-community/nixops-datadog

2. NixOps Core has been updated to be Python 3 only, and at the
   same time, MyPy type hints have been added and are now strictly
   required during CI.

This is all accumulating in to what I hope will be a NixOps 2.0
release. There is a tracking issue for that:
#1242 . It is possible that
more core changes will be made to NixOps for this release, with a
focus on simplifying NixOps core and making it easier to use and work
on.

My hope is that by adding types and more thorough automated testing,
it will be easier for contributors to make improvements, and for
contributions like this one to merge in the future.

However, because of the major changes, it has become likely that this
PR cannot merge right now as it is. The backlog of now-unmergable PRs
makes it hard to see which ones are being kept up to date.

If you would like to see this merge, please bring it up to date with
master and reopen it. If the or mypy type checking fails, please
correct any issues and then reopen it. I will be looking primarily at
open PRs whose tests are all green.

Thank you again for the work you've done here, I am sorry to be
closing it now.

Graham