> I miss one variable in the configuration of the Emperor. > eg. %c - chdir in vassal config > > What is my case: > $ uwsgi --emperor /path_a/conf > > in /path_a/conf/*.ini files are linked to /path_b/project_name/config.ini > > Each project has a several of configuration files, for example: dev.ini, > production.ini etc. > Therefore, I can use in any way with %n > > Directory containing configuration files is different than the target > project directory. > Therefore, I can use in any way with %d > > > It was best to have something like this: > project dir: /path_b/proj1 > project config files: > /path_b/proj1/prod.ini > /path_b/proj1/dev.ini > > in /path_b/proj1/dev.ini: > [uwsgi] > socket = /tmp/uwsgi/proj1.sock > chdir = /path_b/proj1 > spooler = data/spooler > daemonize = data/uwsgi.log > pidfile = data/uwsgi.pid > > or > > [uwsgi] > socket = /tmp/uwsgi/proj1.sock > chdir = /path_b/proj1 > spooler = %c/data/spooler > daemonize = %c/data/uwsgi.log > pidfile = %c/data/uwsgi.pid > > So that spooler pointed to /path_b/proj1/data/spooler > > then: > $ ln -s /path_a/conf/proj1.conf /path_b/proj1/dev.ini > > and run uWSGI in emperor mode: > $ uwsgi --emperor /path_a/conf
Adding those kind of variables (based on the content of the file itself) it will be very hard. But i understand your problem. I have added the %v variable (it point to the vassals dir). The "id" concept is already used in xml files, i would like to find a way to use it in emperor. Another useful feature (i will add it in 0.9.7.1 for sure) will be a "glob" style vassal dir ./uwsgi --emperor /home/*/www/*/wsgi.ini Whenever a user put a wsgi.ini in a special directory in his/her home the emperor will spawn a new instance. (problem 1 of hosting/clouding services is solved). Another set of features will be limiting new instances to avoid unprivileged users to do all sort of mess. Something like: --emperor-uidgid (this will set uid and gid based on the config file owner) --emperor-limit-as (will limit the address space of instances) (problem 2 solved) But the real killer feature will be remote spawn of instances. On a server (for example the server where you run a kind of control panel for your users) you write the config files. The emperor on this server see them and talk with a "emperor-agent" running on another node that will spawn it (obviously you can run the agent on multiple servers to allow auto-clustering). -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
