On 20.04.2011 22:51, Roberto De Ioris wrote: > Check the latest tip: > > --inherit <filename> > > (you can specify it multiple times) > > it will "merge" another config file. This "template" can inherit itself > from another one and so on (beware of circular loops). You can use > variables in it and obviously placeholder. > > for example template1.ini > > [uwsgi] > my_socket_dir = /tmp > master = true > > and config.ini > > [uwsgi] > inherit = template1.ini > processes = 4 > socket = %(my_socket_dir)/foo.sock > > > Emperor has --vassals-inherit. It works in the same way but the templates > will be applied to all the vassals. > > This should cover all of your needs without adding a tons of options :)
Thanks, Roberto! Very elegant and clean solution. Seems like really workable for my needs. In a few experiments with tip result of my init.d script (responsible for defining common options for new instances) was successfully repeated with --vassals-inherit. >> 2. hooks for phases of starting/stopping instances (namely: >> pre-start, post-start, pre-stop, post-stop). > > > need to check a couple of things, but they can map to normal executables > files (script or binary it does not matter). Those scripts/executables > will receive the config filename as the first argument. > The problem is that it would be better that they receive all the options > already parsed in some way to make scripting easier...(i am thinking about > a post-stop hook that will do some magic with pidfile, but to know its > filename it should parse the config file and it will be a PITA). > Probably a uwsgi --get <file>:<key> that parse the <file> and returns the > value for <key> would be very useful and less complex to develop: > > #!/bin/bash > > PIDFILE=`uwsgi --get $1:pidfile` > echo "The pidfile is $PIDFILE" Your vision of hooks is fully suitable for me. I can add to it basically nothing. Did you considered passing of parsed configuration options to hook executable in form of environment variables? >> Autoloading of programming language bridge plugins: python, lua, psgi, >> etc. (without explicit listing in '--plugins' option) is the another >> feature that I'd like to see in uWSGI. >> > > still have not found a good way, the only hack that come to my mind is > loading/unloading all of the plugins in the UWSGI_PLUGIN_DIR until the > option is found. The problem is that dlclose() implementation is not very > clear on how resources loaded with dlopen() will be freed :( Metainformation about options provided by plugin can be extracted at build time, then placed in plugins_dir (near shared library x_plugin.so) in form of parsable text file. Then uWSGI executable should only load and parse text files available in plugins_dir, but not shared libraries. Could it be a reasonable solution? _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
