[Nix-dev] State database in nixops

[Domen Kožar]

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 <tehunger at gmail.com> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150222/1121c479/attachment.html