samueldr changed the topic of #nixops to: NixOps related talk | logs: https://logs.nix.samueldr.com/nixops/
clever has joined #nixops
teto has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
NobbZ[m] has quit [Quit: killed]
Cadey has quit [Quit: killed]
aanderse has quit [Quit: killed]
aanderse has joined #nixops
NobbZ[m] has joined #nixops
Guest4337 has joined #nixops
teto has joined #nixops
Guest4337 has quit [Changing host]
Guest4337 has joined #nixops
Guest4337 has quit [Quit: authenticating]
Guest4337 has joined #nixops
Guest4337 has joined #nixops
Guest4337 has quit [Changing host]
Guest4337 is now known as Cadey
globin_ is now known as globin
globin has joined #nixops
globin has quit [Changing host]
cole-h has joined #nixops
dongcarl has quit [Read error: Connection reset by peer]
abathur has quit [Quit: abathur]
abathur has joined #nixops
tokudan has joined #nixops
energizer has joined #nixops
<energizer> hello, i'm curious what is the benefit of keeping persistent state (https://github.com/NixOS/nixops/blob/master/nixops/statefile.py#L233) over a stateless approach (https://github.com/DBCDK/morph)?
niso has joined #nixops
<DigitalKiwi> not an expert but iiuc there are things you can't do (especially/specifically? with AWS) without persistence
<DigitalKiwi> so vague as to be almost unhelpful :(
<adisbladis> energizer: For the none backend there isn't much point
<adisbladis> But for the other backends like AWS, Digitalocean etc you are provisioning machines
<adisbladis> And need to keep state around to know machine ids and whatnot
<adisbladis> energizer: https://github.com/NixOS/nixops/pull/1264 contains a "memory" backend that's not persistent
<{^_^}> nixops#1264 (by grahamc, 5 weeks ago, open): Example NixOps State Backends
<energizer> i see
<adisbladis> energizer: Nothing is decided yet
<adisbladis> But I'd like for NixOps 2.0 to be stateless by default
<energizer> cool
<energizer> i wonder if some of the state can be reduce by querying the provider for machine ids at deploy time instead of storing them
<infinisil> adisbladis: Does "stateless" in this case just mean no local state?
<adisbladis> infinisil: Yes
<adisbladis> Or.. I mean no state.
<adisbladis> As in the "memory" backend by default
<infinisil> adisbladis: Hm, how does memory backend work?
<infinisil> Hold on I'll check if it's described in the docs somewhere
<infinisil> Hm can't find anything
<gchristensen> every nixop call, the memory backend makes a fresh sqlite db, and the end, poof it goes in to nothingness
<infinisil> Oh I see, what about the ssh key though and other things that need to persist?
<gchristensen> if you need them, you shoudn't use the memory backend
<infinisil> So nixops now works without having its own ssh key?
<gchristensen> it always has, but the memory backend does silly things atm(one reason it isn't merged) -- like creating a new ssh key every deploy
<adisbladis> infinisil: That's a separate PR https://github.com/NixOS/nixops/pull/1247
<{^_^}> nixops#1247 (by adisbladis, 7 weeks ago, open): Make it possible to use Nixops without automatic SSH key provisioning
<infinisil> Ah nice
<infinisil> Another thing that should probably persisted is the stateVersion
<infinisil> Or maybe the memory backend could just require users to set stateVersion themselves
<gchristensen> yeah, I mean, using the memory backend makes your responsible for all that
<globin> yeah we just set stateVersion in our base profile
<infinisil> Is there anything other than ssh key and stateVersion that's important?
<gchristensen> depends if you use aws, encryptedLinksoTo, etc
<infinisil> Ahh
andi- has quit [Ping timeout: 240 seconds]
andi- has joined #nixops