On the long run NixOps needs a cleaner API to handle the state. The result could be centralized deployments (via web api) or just a plaintext file stored in git.
PS: Making sure you're aware of https://github.com/zalora/upcast On Sat, Feb 21, 2015 at 4:06 PM, Thomas Hunger <[email protected]> wrote: > > 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. > >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
