It shouldn't be much work to support any SQL db by refactoring nixops to use sqlalhemy orm. On 21 Feb 2015 13:10, "Ryan Trinkle" <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> >> >> _______________________________________________ >> nix-dev mailing list >> [email protected] >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
