samueldr changed the topic of #nixops to: NixOps related talk | logs:
<DigitalKiwi> how did the meeting go
<cole-h> It was fun. Got the XML -> JSON PR merged
<cole-h> Also talked to aand*rse about the `-d` flag, I believe (idk what the backstory on that was -- removal I think?)
* cole-h was an impartial observer
<DigitalKiwi> why json why not yaml isn't that the new hotness
<cole-h> I believe it was Nix's XML representation to JSON representation, not as configuration or whatever
<DigitalKiwi> nix dhall 2020
<abathur> all of the cool kids write their data in ham sandwich
andi- has quit [Remote host closed the connection]
andi- has joined #nixops
pbb has quit [Ping timeout: 265 seconds]
pbb_ has joined #nixops
cole-h has quit [Quit: Goodbye]
<manveru> awesome, that XML was really annoying...
lordcirth has quit [Read error: Connection reset by peer]
lordcirth__ has joined #nixops
<manveru> we found some more python3 issues in nixops/nixops-aws...
<manveru> will try to make a PR for this later if i get some time
<manveru> but i guess one shouldn't trust those type annotations after all :P
<manveru> gchristensen: so... if we want to fix our hydra builds for nixops expressions... is there a way to get eval-machine-info that has the correct plugins imported?
<manveru> because i don't see a way to actually get those without running `nixops`, which is a no-go
<manveru> since plugins aren't in `propagatedBuildInputs` for the `withPlugins`, the `pluginNixExprs` aren't populated anymore it seems
<gchristensen> 09:34 <manveru> but i guess one shouldn't trust those type annotations after all :P
<gchristensen> if you're finding problems with them, please fix them :)
<gchristensen> they've been very useful
<gchristensen> this is for building nixops networks in hydra?
<manveru> this says it's a `str`
<manveru> but it was `bytes`
<manveru> so no clue what the type checking should do, but it didn't stop concating that to a string
<gchristensen> sounds like another rebase issue :/
<gchristensen> but didn't the type hint?
<gchristensen> something is wrong if you've got bytes there
<gchristensen> yeah
<gchristensen> the easier fix is to just make config_paths from bytes to str
<gchristensen> looks like hard mode, trying to merge the flake branch and master and your changes
<manveru> jup
<manveru> gotta get rid of the flakes stuff...
<manveru> but haven't had time for it yet, really need to fix our deployment first
<gchristensen> I'm a bit confused about why you've bumped to latest master so quickly, instead of staying back a bit?
<manveru> because of the changes adisbladis made for plugins
<manveru> and we wanted to upgrade to python3
<manveru> so he ported the `withPlugins` to nixops for us :)
<manveru> which was on master
<gchristensen> I thought the withPlugins fix was to deal with problems you were hitting once you were already on master?
<gchristensen> interesting
<manveru> well, got everything working except for the hydra tests
<gchristensen> cool
<gchristensen> the hydra tests being actually building all the machines, in hydra
<manveru> yes
<gchristensen> cool
<manveru> `The option `nodes.deployer.deployment.ec2' defined in `/nix/store/kpsbkmivzwzdl1bcmp5ykdrlz240nmvb-source/nix/network.nix' does not exist.`
<manveru> this seems like it might be because nixops doesn't find the plugin nixos modules
<gchristensen> how do you do that? I've never seen nixops used in hydrabefore, so not really sure what approach you've taken :)
<manveru> basically run eval-machine-info in hydra
<gchristensen> interesting
<gchristensen> I'm trying to think of a way to do this which doesn't involve some form of IFD :/
<gchristensen> heck, adisbladis managed to make all of poetry2nix work without IFD -- he might have a way if we use some conventions around where the nix files live
<gchristensen> or maybe something better
<manveru> i think i have a solution
<manveru> but need more time to tinker :)
<gchristensen> it would be cool to have a way to support this ... you don't use the state file during the build, though, right?
<gchristensen> just build each machine attribute?
<manveru> gchristensen: exactly
<gchristensen> I look forward to seeing your solution :)
<gchristensen> and making it, like, documented and tested too :P
<gchristensen> so we don't break it again :D
<manveru> hehe
<gchristensen> maybe intsead of the nix_exprs function we should use pyproject.toml entrypoints or something
<adisbladis> What's bad about nix_exprs?
<gchristensen> so that hydra could evaluate a .nix file with plugin loading
<manveru> adisbladis: basically the passed plugins from `withPlugins` needed passing as `propagatedBuildInputs` in the passthrough
<adisbladis> Hmm
<adisbladis> How does propagating them help?
<manveru> of course nixops doesn't have a `nix/default.nix`, so i had to exclude that, otherwise you could just reuse the plugins
<manveru> it needs to add the plugin nix files to the imports
<manveru> so i don't think going through poetry would be an option here anyway :)
<adisbladis> Ahh, I see
<adisbladis> Hmm
<adisbladis> I mean, it must be?
<manveru> sure, but i don't mind IFD...
<manveru> we use haskell.nix too much to worry about that :P
<adisbladis> manveru: I think we could call nix_exprs in the plugin env builder and stick those paths somewhere in $out/nix-support/ ?
<manveru> yeah
<adisbladis> In fact, I don't see the current solution working very well anyway. We need some more magic.
<manveru> alright... will clean up this nixops branch now so it gets a chance of going upstream :)
<adisbladis> Let's say you have 2 plugins "foo" and "bar", foo depends on bar and you need foo so you: `nixops.withPlugins(ps: [ ])`, now we don't know to load the nix exprs from bar because is only looking at the `propagatedBuildInputs` attribute which is not including bar.
<adisbladis> So I think we really need that plugin env builder magic.
<adisbladis> gchristensen: ^
<manveru> alright
<{^_^}> nixops#1319 (by manveru, 18 seconds ago, open): add nixops eval subcommand
<manveru> hope that's a bit cleaner now :)
<manveru> but please do test before trusting me... haven't done so yet myself ^^;
<manveru> really wish nixops used niv, never can get that shell.nix to work
<adisbladis> I was just mentioning to gchristensen the other day we should pin the nixpkgs used for development
<adisbladis> I'm open to depending on niv for shell.nix (but not for default.nix/release.nix)
<manveru> yeah, that'd be enough for me
<manveru> adisbladis: gchristensen: updated the comment and it's green now...
<manveru> gonna do a bit more testing to make sure it works :)
teto has joined #nixops
<manveru> all good from me
<manveru> seems like `nixops check` is still broken with aws
<manveru> again with the sqlite3 error
<manveru> this time i'm pretty sure it's not our rebase :)
<manveru> gchristensen: regarding the `preDeploy` stuff, it kinda depends on our nixops submodules implementation... which is kind of a breaking change to nixops
<manveru> so we haven't made a proposal for that yet, but maybe nixops 2.0 would be a good time for breaking stuff? :)
<gchristensen> nixops 2.0 is a great time for such breakage :)
<manveru> adisbladis: any reason you removed the -unencrypted links? :)
<gchristensen> are you using encryptedLinksTo?
<manveru> is still broken, so i couldn't try that
<manveru> no
<manveru> but we use hostnames
<gchristensen> interesting
<manveru> and this not only removed *-unencrypted but also hostnames for other machines
<gchristensen> double-interesting
<gchristensen> so do you actually use hostname-unencrypted?
<manveru> not sure why, but this quick fix worked
<manveru> yes
<gchristensen> huh
<manveru> we set up wireguard links over those names
<gchristensen> adisbladis: this is an area that unit tests could could easily be useful. it'd be cool to find a way to do that
<manveru> i'd be ok if at least the normal hostnames were still there
<adisbladis> manveru: That was unintentional.
<gchristensen> from your diff it looks like the normal ones should be there
<gchristensen> oh
<gchristensen> no
<gchristensen> I'm looking at the knownHosts bit
<adisbladis> Those with the `-unencrypted` suffix should be gone, but not adding the other hosts.
<adisbladis> gchristensen: I think we should split the internal config generation to also use plugin hooks
<adisbladis> That would make unit testing easier
<adisbladis> Hm? Looks like it should be behaving correctly?
<gchristensen> manveru: can you make a ticket for the dropped names, or even better a PR adding it back?
<manveru> maybe on monday... i'm spent today :|
<gchristensen> cool, no worries. I guess we should make a ticket then?
<manveru> if you don't mind
<manveru> sorry, my hands are pretty much broken now
<gchristensen> I 100% get that
<gchristensen> take it easy manveru, thanks for the issues and reports :)
<gchristensen> nice to have some users :)
evanjs has joined #nixops
lordcirth__ has quit [Remote host closed the connection]
lordcirth__ has joined #nixops
cole-h has joined #nixops
abathur has quit [Quit: abathur]
lordcirth__ has quit [Read error: Connection reset by peer]
lordcirth has joined #nixops
abathur has joined #nixops
lordcirth has quit [Read error: Connection reset by peer]
lordcirth has joined #nixops
<gchristensen> I'd love to have some people who know things about things take a look at this PR:
<{^_^}> nixops#1323 (by adisbladis, 2 hours ago, open): Use rsync instead of scp for file copying
<gchristensen> aminechikhaoui: ^
<cole-h> (Disclaimer: the following comment is basically a nothingburger) I can't say anything about the Python, but I do like the idea of using rsync > scp
<gchristensen> oh?
<lordcirth> The openssh devs themselves said to please stop using scp
<lordcirth> So yeah :P
<gchristensen> oh?
<lordcirth> Yeah, it came up during that scp CVE a while back
<gchristensen> huh
<gchristensen> okay but please make a comment to that effect? :)
<lordcirth> what, on the pr?
<gchristensen> yea
<lordcirth> Ok, well, I'll try to find the reference first
<gchristensen> thanks :)
<Xe> is it a good idea to use nixops to manage an existing nixos machine?
<lordcirth> Xe, it works fine. Just remember that anything you don't copy into the nixops config (like users!) will vanish
<gchristensen> and your hardware-configuration.nix too
<gchristensen> it is a fine idea, but consider using nixops deploy --dry-activate and make sure you're not missing anything
<Xe> so if i have a nixops deployment point to the existing configuration.nix file i have in a git repo i should be fine?
<gchristensen> should be
<Xe> (which points to the hardware-configuration.nix file, etc)
<Xe> how about things like wireguard keys?
<Xe> do the key files get read on the remote host or the local one?
<gchristensen> your wireguard keys should stay on the remote, and nix shouldn't be touching them
<Xe> cool
dongcarl has quit [Quit: Ping timeout (120 seconds)]
<Xe> yep it works perfectly
dongcarl has joined #nixops
<gchristensen> nice!
<Xe> i hope this will solve my secret management questions
teto has quit [Ping timeout: 272 seconds]
teto has joined #nixops