[Nix-dev] State database in nixops

Ryan Trinkle ryan.trinkle at gmail.com
Sat Feb 21 22:10:43 CET 2015


At skedge.me, we've recently switched over to nixops for all deployments,
so we've run into this issue as well.  We're moving towards the shared
machine approach, but it's not completely satisfying, because it creates a
single point of failure.

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.

On Sat, Feb 21, 2015 at 3:52 PM, Domen Kožar <domen at dev.si> wrote:

> Best way is to have a shared machine to deploy from.
>
> Another option would be to create a web interface for nixops.
>
> On Fri, Feb 20, 2015 at 7:05 AM, Thomas Hunger <tehunger at gmail.com> wrote:
>
>> Hi,
>>
>> I've been a happy user of nixops for my own projects for a while. It
>> works fine as a single user tool but we found it to be tricky to use with
>> multiple developers, or even just a CI system that calls nixops deploy.
>>
>> One issue we had is absolute paths in the state. I.e. if I "nixops
>> export" my state and then import and use it on e.g. the jenkins account I
>> need to adjust the absolute paths.
>>
>> Another issue we have is that checking a sqlite database into git isn't
>> great for reviews.
>>
>> We have a semi-working system now where jenkins calls "nixops deploy -s
>> /var/common-state/project.sqlite ..." on our deploy server, and we have
>> local copies of that state for emergency deploys.
>>
>> First: How are other people solving collaboration on nixops state?
>>
>> Secondly: Is there any interest in extending nixops to have a text (e.g.
>> protobuf-ascii) state file with relative paths that could be checked into
>> git? There are a few unclear design choices, e.g. what to do with ec2
>> backups. But for our purposes it would be better to use AWSs list of
>> volumes as the source-of-truth for backups (e.g. by adding more tags).
>>
>> best,
>> Tom
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150221/7800297a/attachment-0001.html 


More information about the nix-dev mailing list