WIP: Add deploy without creating a state file #1248
Conversation
|
main thing i can see being lost with this change, is that the but the user must now manage nixops rollbacks also require the uuid of the deployment to remain constant, so it can find the generations |
There was a problem hiding this comment.
Overall, I like this a lot.
I think --no-state should not be an option. Instead, I think it should be a property of the network.nix itself. For example, a user who creates a network which spawns a bunch of wildly expensive boxes, but passes --no-state... and then NixOps fires-and-forgets a big bill for them.
In cases like this, I think the NixOps should refuse to do things like create resources when state is disabled. Thus, always be applied (or not applied), thus part of the network definition.
adisbladis
force-pushed
the
smash-the-state
branch
2 times, most recently
from
c26ccde
to
02001ca
Compare
grahamc
force-pushed
the
smash-the-state
branch
from
02001ca
to
1398e9b
Compare
|
I just force-pushed a rebase on to master. |
grahamc
force-pushed
the
smash-the-state
branch
from
1398e9b
to
9f19b30
Compare
adisbladis
changed the title
adisbladis
changed the title
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
|
#1264 which builds on this is a better and more comprehensive solution. Closing. |
Create an in-memory SQLite db if
--no-stateis passed to deploy.This is probably the easiest way possible for us to add support for deployments without using a state file.
If
--no-stateis passed a create is implicitly done in the same process.While this works perfectly fine with the
nonebackend it's marked WIP because it needs docs.Based on top of #1240 since they touch a lot of the same code & meant to be used together with #1247.