-
-
Notifications
You must be signed in to change notification settings - Fork 362
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add recovery feature #2
Labels
Comments
ghost
assigned edolstra
Mar 21, 2012
aszlig
added a commit
to aszlig/nixops
that referenced
this issue
Nov 4, 2013
The increase of the server name length was part of my wishlist to the folks at Hetzner which they implemented in the meantime (before the maximum length was 50 chars which leaves room for the UUID but truncated host names at 6 chars). So thanks to the Hetzner Robot team for increasing that limit. For us, this means that we can store the full vm_id in the Robot which currently only makes it easier to distinguish individial NixOps hosts in the Robot. In the long term however, it could be useful reconstructing/recovering deploments (see NixOS#2). Signed-off-by: aszlig <[email protected]>
aszlig
added a commit
to aszlig/nixops
that referenced
this issue
Nov 4, 2013
The increase of the server name length was part of my wishlist to the folks at Hetzner which they implemented in the meantime (before, the maximum length was 50 chars which leaves room for the UUID but truncated host names at 6 chars). So thanks to the Hetzner Robot team for increasing that limit. For us, this means that we can store the full vm_id in the Robot which currently only makes it easier to distinguish individial NixOps hosts in the Robot. In the long term however, it could be useful reconstructing/recovering deploments (see NixOS#2). Signed-off-by: aszlig <[email protected]>
Merged
Any word on this? Having to maintain a state file which could potentially be lost is keeping people away from using NixOps. Also I have lost my state file and I am not sure how to rebuild it. |
#1264 implements state backends, and those backends could implement backups. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If the state file of a Charon deployment is lost, it would be nice if it could be reconstructed automatically given the UUID of the network.
A related feature would be to enumerate all known machine instances in all backends (along with their network UUIDs).
So you could recover like this:
The text was updated successfully, but these errors were encountered: