[Nix-dev] Multiple MySQL instances (or nginx/apache/...)
How should this be written in the future ?
I've submitted a pull request which tries to change not much lines to
reach my goal - however I agree that it might not be the perfect
solution yet: https://github.com/NixOS/nixpkgs/pull/5542
This change adds a parameter moduleName to the mysql module which then
gets used for most defaults (pid file, data dir and so on)
{ moduleName ? mysql}: # eg pass mysql2 to add a second mysql
services.${moduleName} = {
enable = mkOption {
default = false;
};
user = mkOption {
default = moduleName;
[...]
Final usage look like this:
imports = [
(import (nixpkgs+/nixos/modules/services/databases/mysql.nix)
{moduleName = mysql_on_tmp; })
]
services.mysql_on_tmp.enable = true;
services.mysql_on_tmp.port = 3307;
services.mysql_on_tmp.package = pkgs.mysql55;
services.mysql_on_tmp.dataDir = /tmp/mysql;
services.mysql_on_tmp.socketDir = /tmp/mysql_tmpfs.socket;
ids.uids.mysql_on_tmp = 2;
ids.gids.mysql_on_tmp = 2;
If there are existing beter solutions let me know and or comment to
either the pull request or this thread.
I guess the most interesting point is uid/gid handling.
Introducing a style will affect almost all services ..
lethalman proposes such style:
services.mysql.instances.name = ...
I agree that this style is nicer. Do you agree?
Should services.mysql be mapped to services.mysql.instances.default then?
Then backward compatibility could be preserved.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple MySQL instances (or nginx/apache/...)
Let's not break the discussion in two places. It started on the github
issue and can be kept there.
On Sat, Jan 3, 2015 at 2:23 PM, Marc Weber marco-owe...@gmx.de wrote:
How should this be written in the future ?
I've submitted a pull request which tries to change not much lines to
reach my goal - however I agree that it might not be the perfect
solution yet: https://github.com/NixOS/nixpkgs/pull/5542
This change adds a parameter moduleName to the mysql module which then
gets used for most defaults (pid file, data dir and so on)
{ moduleName ? mysql}: # eg pass mysql2 to add a second mysql
services.${moduleName} = {
enable = mkOption {
default = false;
};
user = mkOption {
default = moduleName;
[...]
Final usage look like this:
imports = [
(import (nixpkgs+/nixos/modules/services/databases/mysql.nix)
{moduleName = mysql_on_tmp; })
]
services.mysql_on_tmp.enable = true;
services.mysql_on_tmp.port = 3307;
services.mysql_on_tmp.package = pkgs.mysql55;
services.mysql_on_tmp.dataDir = /tmp/mysql;
services.mysql_on_tmp.socketDir = /tmp/mysql_tmpfs.socket;
ids.uids.mysql_on_tmp = 2;
ids.gids.mysql_on_tmp = 2;
If there are existing beter solutions let me know and or comment to
either the pull request or this thread.
I guess the most interesting point is uid/gid handling.
Introducing a style will affect almost all services ..
lethalman proposes such style:
services.mysql.instances.name = ...
I agree that this style is nicer. Do you agree?
Should services.mysql be mapped to services.mysql.instances.default then?
Then backward compatibility could be preserved.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
NixOS Linux http://nixos.org
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] hydra.nixos.org stopped scheduling jobs
On 01/02/2015 06:54 PM, Peter Simons wrote: hydra.nixos.org shows 0 running jobs despite a queue worth 56,000+ entries? It seems building OK now. I don't know if anyone has intervened... Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple MySQL instances (or nginx/apache/...)
Hi Luca, Let's not break the discussion in two places. It started on the github issue and can be kept there. one advantage of breaking it up is that I can take note of it and add that I'm currently working on a prototype of my earlier algebraic services proposal, which among other things allows you to run as many MySQL and other service instances as you like. =) But don't hold your breath. It could take a week or two before I can present my first prototype. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple MySQL instances (or nginx/apache/...)
Excerpts from Ertugrul Söylemez's message of Sat Jan 03 14:05:05 + 2015: But don't hold your breath. It could take a week or two before I can present my first prototype. Maybe you can sketch your idea for the sake of discussion? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple MySQL instances (or nginx/apache/...)
Hi Marc, But don't hold your breath. It could take a week or two before I can present my first prototype. Maybe you can sketch your idea for the sake of discussion? Allow me to send you to the thread in question: http://lists.science.uu.nl/pipermail/nix-dev/2014-December/015362.html The original discussion was about replacing systemd, but you can just scroll down to my proposal. I really should have started a thread of its own for that. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Let me comment:
- Is systemd a step backwards?
* upstart didn't even implement logging, did it?
* some more things I think systemd does better than upstart (eg socket
activation)
However I agree that journalctl is horribly slow.
- Must the module system or systemd go away? I don't think so.
why not add a new option
services.my_modular_thing = mysql postgres bitlbee ..;
But what is the goal?
domain_1 = foreign_domain www.example.com;
domain_2 = domain_managed_by_X www.foo.bar;
ssl_cert = yyy;
php_app = new wordpress_instance {
databases = [
{ type: mysql;
timeouts: foobar;
require_mysql_import_in_path = true
}
];
http = [
{ domains = [domain_1 domain_2]; port = 8080; }
{ domains = [domain_1 domain_2]; port = 443; inherit ssl_cert; }
];
}
container_1_amazon_eu = {
apps = [ php_app ];
}
container_2_load_balancer_with_instances {
apps = [];
}
realise [container_1_amazon_eu container_2_load_balancer_with_instances ];
But still, how to move the app from container_1_amazon_eu to
container_2_load_balancer_with_instances ?
Then due to TTL in DNS there is much more to take into account such as
HTTP proxies, mysql replication (if you want minimal down times) and
whatnot.
Thus a
php_app.move_to_container_with_minimal_downtime(container_2_load_balancer_with_instances)
can this be done with a configuration file at all?
what should move_to_container_with_minimal_downtime ideally do?
1) prepare the second container (create user account, database)
2) start mysql replacation (eg lock database in container 1, create
btrfs snapshot, read replacation state, unlock, copy btrfs backup to
container_2_load_balancer_with_instances, start replication, wait
till its in sync)
3) stop web app @ container_1_amazon_eu, setup http proxy to new IP,
4) garbage collect (thus delete all account/database stuff @
container_1_amazon_eu)
How can this be expressed using a simple text file ?
Some things just require global state IMHO ..
So what do we really want ?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Request for comments: pinky-promise determinism
I don't like to use the git hash, as it is SHA1 and not fit for use wrt integrity. I think that would be a regression wrt the complex tricks that Georges referred to. Would it be possible to create a git wrapper that does the make_deterministic_repo step in a transparent manner for cargo and have this git be in the build environment? Alexander On Fri, Jan 2, 2015 at 9:07 PM, Wout Mertens wout.mert...@gmail.com wrote: Another use-case: providing the same input hash, based only on version, for gcc and cross-gcc on another platform. Ditto for ccache and distcc. On Fri, Jan 2, 2015, 14:56 Shea Levy s...@shealevy.com wrote: For dirty dirty hacks, you can set __noChroot = true and get access to the network. On Jan 2, 2015, at 1:09 PM, Georges Dubus georges.du...@gmail.com wrote: Hello everyone I would like to propose compromise in the purity rules of non-fixed-output derivations, and hear what you think about it. # Rationale There are a few situations where derivations play the role of fixed-output derivation, but the hash of their output is not fixed. Some examples: - fetchgit derivations when the .git must be kept. The .git directory is incredibly hard to make deterministic, as this require tweaking with implementation details: purging any commit that might have been downloaded from the server, that may have no link with the reference we are using. - cargo, the package manager for the rust language, uses git to download its database, and to check it is up-to-date. The same problem as with fetchgit arise, with the increased trouble that we are now tweaking the implementation detail of an implementation detail. However, we can trust that, even though the .git is not binary identical in each situation, the result of the git commands we could use in the packaging task is always the same. # Proposition I propose a new kind of derivation that would be identical to the current non-fixed-output derivation, but without any restriction on its access to the outside world. The documentation should state that this kind of derivation is dangerous, and should only be used when a trustworthy tool is used (since the tool is trusted to be deterministic in its behaviour). This new derivation could be used for dirty hacks, but this should be discouraged by the documentation, and never accepted inside nixpkgs. # Conclusion The inclusion of this new kind of derivation would allow a satisfying implementation of leaveDotGit for fetchgit, one that does not rely on complex tricks[1], and allow me to implement cargo support without relying on non-future-proof internals tweaking. However, this would be at the cost of including a new kind of derivation that is much less satisfying, and that could, if misused, come back to bite us. I'd love to hear what you think about it. [1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/nix-prefetch-git#L198 -- Georges Dubus ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] less: When assumptions ruin the world
Just a note for those who are annoyed that less will clear the screen on quit. export LESS=-X On Fri, Jan 2, 2015 at 4:30 PM, Ertugrul Söylemez ert...@gmx.de wrote: Hi Eelco, There is a very good reason for this principle. If a program does more than what it's intended to do, then it hurts composability. There shouldn't be an issue with composability here, because Nix will only run the pager when stdout is a terminal. So things work fine if you pipe Nix into another command. Let me give you an example where this assumption fails: Listing the current generations from your shell profile. In fact something very similar happened to me, which motivated me to start this thread: The change broke my assumption that Nix can be used safely from a shell script. Nothing bad happened, but one day was wasted, because a script stopped for `less` without my knowledge. I really believe that projects should start as non-interactive script- and command-line-friendly programs /by default/. I'd go as far as to call this a good design principle. Frontends can always be made. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
