[Nix-dev] State database in nixops

[Thomas Hunger]

> What I'd like much better is an option to use an external database; then I
> could use a replicated cluster or something like that to eliminate the
> single point of failure.  The last thing I want is my ops team being locked
> out of nixops during an emergency.
>

nixops accesses the .nix config file via an absolute path stored in the
sqlite database  ("nixExprs"). An external database doesn't help unless we
remove that absolute path restriction somehow and also distribute the
nixExprs file to every machine that might run nixops.

I'm not too fond of a central (potentially replicated) DB because it comes
with its own set of problems like permission management, requiring
bootstrapping (where to store the nixops state for the database server?)
etc.

We'd be interested in 1) an audit trail, 2) no single point of failure, 3)
light infrastructure.

On top of the 3 points I mentioned above we'd also be interested in
avoiding storing ephemeral state like ec2.backups and configsPath.

I think keeping state in a text file in git could achieve the above
requirements but I'm also sure that there are many other good ways to solve
this.

@Domen: In our experience deploying from a shared machine doesn't work well
[1].

best,
Tom

[1]
Long-ish:
E.g. we have an always-online server with all our SSH and Amazon
credentials on it. We're using instance IAM roles so it's not all bad.
Also, who's deploying to that server?
To deploy we SSH into that server, pull the latest git version and then
call nixops. If there is an issue with the config we fix it locally, push
to git, pull on server, deploy. That's a bit tiresome.
We also have a CI server which deploys for us, but that's not the same
server as the common one we use for manual deploys (which are unfortunately
necessary on occasion). So we have two copies of the state which has
already caused some problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150222/034d9fec/attachment.html