Release 2.0 old tracking issue

[grahamc]

• move this list to a Project https://github.com/NixOS/nixops/projects/4
• Get mypy types exposed for plugin developers
• Update AWS plugin for py3 Migrate nixops-aws to python3 nixops-aws#37
• Update vbox plugin for py3 Poetry2nixify nix-community/nixops-vbox#3
• Update hetzner plugin for py3 Introduce poetry(2nix), GitHub Actions, blackify all the files nixops-hetzner#9
• Solidify the plugin dev / build experience Use Poetry & Poetry2nix for environment and plugin management #1256
• state backends Example NixOps State Backends #1264
• explore terraform integration @adisbladis looked at this and thinks it can/should be a plugin (https://github.com/adisbladis/nixops-terraform).
• explore vault integration for environment variable secrets Vault Integration for Secrets #1289
• identify old features to delete
• perform real life integration tests with real servers and real providers on every PR, including using external plugins Deploy as part of CI #1290
• allow specifying the version of Nixpkgs from within the network.nix expression Specify NIX_PATH / nixpkgs from within a network's expression itself #1291

features to delete or move to plugins:

• encryptedLinksTo support
• autocrypt?
• backups?
• storeKeysOnMachine

[jonringer]

Once NixOS/nixpkgs#104726 gets merged and back-ported, people will have to explicitly add:

     {
       permittedInsecurePackages = [
         "python2.7-cryptography-2.9.2"
       ];
     }

for nixops to work.

[adisbladis]

Hello
Are there any plans to officially release 2.0 soon? ^^
Thanks,

The main blockers at the moment are:

• State backends Example NixOps State Backends #1264
  This PR restricts what paths NixOps checks for deployment expressions to only network.nix or flake.nix and I'd really like to see some more input on that implication before we go ahead and merge.

• Testing tests: Add functional tests using NixOS in Podman (Docker) #1326
  I'm not happy at all with this testing approach. The only reason for the design is that it works in Github Actions. Preferably we'd use the VM testing framework but that doesn't have acceleration in CI.

@tewfik-ghariani @grahamc (and also anyone else interested): Would you be up for a review call either this week or the next and try to push NixOps 2.0 across the finish line? There really isn't much blocking us at the moment and it's a shame that those PRs have gone unmerged for so long.

[tewfik-ghariani]

@jonringer I don't think that would be an issue when using nixops 2.0 as that package has been upgraded in nixops-gcp :
https://github.com/nix-community/nixops-gce/blob/bc94673f9aa6abd9949ecbba86dbbec05f5f7242/pyproject.toml#L12

@adisbladis Thanks for summary! Is there a chance we can postpone the 'State Backends' changes a bit? Let's say move it to 2.1 release? I believe it's better to not rush it and test it properly and the nixops 2.0 contains many ground breaking changes that the community would like to take advantage of the soonest possible

Regarding the "Testing" PR, I agree that scheduling a review call would be the best approach to unblock the merge and the release of 2.0

cc @AmineChikhaoui

[jhillyerd]

Given 1.7 is somewhat broken, I'd also like to see 2.0 sooner. I expect a number of people try 1.7, realize it's out of date, come to this repo to try and use 2.0, and give up.

[jonringer]

@jonringer I don't think that would be an issue when using nixops 2.0 as that package has been upgraded in nixops-gcp :
https://github.com/nix-community/nixops-gce/blob/bc94673f9aa6abd9949ecbba86dbbec05f5f7242/pyproject.toml#L12

Yes, but all versions of nixops in nixpkgs are based on the 1.7 python2 build. I'm aware the the current dev branch of nixops uses python3, but that means that people will be required to package this outside of the repo for them not to be broken (or inconvenienced and vulnerable)

EDIT:
Since you don't think this will be an issue, I will move foward with marking the package as vulnerable on nixpkgs

[mkg20001]

In light of the package being vulnerable and outdated I feel like NixOS/nixpkgs#83548 should get finished up and merged, so people wanting to try the version 2.0 can at least do so without further fuzz (the package could also be mentioned on the readme of this repo)

[calbrecht]

There is more to do for the nixops-hetzner plugin than just merging NixOS/nixops-hetzner#9 to be compatible with nixops 2.0. I managed to get the subcommands info ssh and check running in calbrecht/nixops-hetzner#master. I guess deploy will work too, but would not verify yet. Also i managed to get two plugins work together within a single nixops derivation on the latest nixpkgs master in calbrecht/nixops-overlay#main/default.nix, fyi.

[dotlambda]

Once NixOS/nixpkgs#104726 gets merged and back-ported, people will have to explicitly add:

     {
       permittedInsecurePackages = [
         "python2.7-cryptography-2.9.2"
       ];
     }

for nixops to work.

A similar thing is the case with NixOS/nixpkgs#111322.

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/tweag-nix-dev-update-7/11552/1

[Mic92]

nix-community is switched to nixopsUnstable now due to this: nix-community/infra#57

[deepfire]

This gets excitingly close!

[devhell]

@deepfire Right? I'm really excited too!

[roberth]

Some important issues around the new state handling and locking. Fixing these results in breaking changes, so must be part of this major release.

• How do -d and choice of flake attrs interact? Create multiple networks from the same flake #1451
• Should we have a -d-like parameter to pick a remote state dynamically? (again, -d, as implemented, is not suitable for remote state, because it locks every deployment instead of just one)

Making remote state and locking usable (non-breaking, but quite needed)

• Actually use the state file for host keys Always provide our known_hosts in addition to user known_hosts #1464
  • Let NixOps provide known_hosts independently of user known_hosts nixops-aws#141
  • gcp
  • none "none" machine type should record host key (known_hosts) #1466
• Non-exclusive locks, lock activity descriptions, release lock during ssh, override lock for ssh Locking usability improvements #1470

[roberth]

The generated option docs are missing. They have been for a long time. Might these be a victim of the plugin architecture and repo split? This is definitely a blocker.

[JanCVanB]

Will NixOps 2.0 support macOS?

[roberth]

Project board

https://github.com/NixOS/nixops/projects/4

Please add (or mention here so we can add):

• Issues that impede usability
• Improvements to documentation
• Important changes that require changes to user expressions

[talyz]

The state backends and the general workflow still needs work done and decisions need to be made on how they should work. Quoting my comment on #1264:

Yeah, the legacy backend was broken by this, since it now ignores the nixAttrs state attribute. I've solved this by using the require attribute to import the deployment files from the network file. Specifying the network file is however cumbersome, since the --network flag currently expects a directory, not a file. To make it easier, I've opened #1480.

With that in place, I think we could essentially drop deployments altogether without losing granularity: instead of running nixops deploy -d my_deployment you'd get the same result by running nixops deploy -n my_deployment.nix, as long as my_deployment.nix requires the appropriate files and specifies the backend to use. Note however that this strategy doesn't work with the current legacy backend, since it doesn't allow choosing where the state is stored. A simple json file backend based on import/export, like @roberth is suggesting, would solve this.

Dropping deployments would mean people would have to split their deployments into separate networks, but I think it would reduce complexity and confusion immensely.

[dzmitry-lahoda]

I tried nixos-generators + terranix combo, looked great, so complicated (created/commented some issues on terranix to improve). I could be interesting if nixops to abandon to write is own Python provision layer and just go with Terraform plugins (run them). So NixOps would concentrate doing nix magic of wiring things (I wire generate image as variable into terraform and deploy new VM after change of nixos config - sure I would optimize later just use Cachix Deploy or SSH to switch config only, but that is later - may be I will mount config via terraform into VM :) ).

Also would be greate if NixOps abstracts away pull vs push deployment somehow. And use (like home manager, nixos-generator, nixos itself full end to end module system (if not yet). As of now I see it only partially so.

Oh, we used NixOps from master for a while. So it harder to handle then combo above as i feel.

UPDATE:

just made end to end example fully in nix, from nixos custom amazon images, to domain name system to vm insances and then nixos-rebuild nixos updates of nixified server nodes releases ggxchain/ggxnode#45 .

from pain points which are different from nixops, these so can be fixed. how to connect output of terraform to nix input. so that commands which run nixos-rebuild know what to call (actually generating nixos configuration using terraform output). part of issues can be solved running nix as hooks under terraform nix -> terraform -> nix https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax

another missing peace is reading terraform lock file and getting all plugins mounted (plugins can be mounted via https://github.com/nix-community/nixpkgs-terraform-providers-bin, but need reader).

and sure what is lacking, evaluating nix code druing terraform build. HCL is like 2 languages, those that evaluates into JSON spec(that what nix works well), and another one which runs on resource/data attributes to produce attributes to be used for other resources. when terraform binary starts, it has no all data, so cannot evaluate on start. so some plugs of terraform for loops and maps are used as strings. so in theory can be solved by having converter of nix to hcl functions during derivation.

> resources.dns_zone is created before domain name
resources.domain.nameservers = [for n in resources.dns_zone.ns : name => n )]

in terranix

resources.domain.nameservers = "\${[for n in resources.dns_zone.ns : name => n )]";

so this is not type checked and is injection of foreign language.

does nixops allows to evaluate nix expression based on output response from cloud?

basically, can nix have https://developer.hashicorp.com/terraform/language/expressions/references#values-not-yet-known unkown values system like?

[nixos-discourse]

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/unknown-values-propagation-in-nix-like-in-hcl/26743/1