Sorry, didn't notice the patch that was submitted above... that patch seems perfect for me. As far as the objections around putting it in core, it's not a templating language, just an extension to the string formatting mechanism already present in supervisord, and I don't see a problem including it in core. The only possible thing I could think of to change would be to have a global 'environmentVars' setting that allows you to explicitly include only certain vars, to provide a cleaner environment and to keep configs from accessing certain variables.
On Wed, Jan 19, 2011 at 14:54, David Bronke <[email protected]> wrote: > I'd also be interested in this, mostly because I use supervisord across > large numbers of servers, with the same configuration file on each, and it > would be useful to be able to access machine-specific environment variables > (especially, say, HOSTNAME) in the configuration file so I don't have to > manually generate a separate config for each server when rolling out > configuration changes. > > If the consensus is that this design (simply allowing configuration files > to access anything in os.environ) is solid, I'd be willing to implement it > and submit a pull request. Does this sound like a good way to get this > functionality? > > > On Mon, Dec 20, 2010 at 13:13, Mike Lewis <[email protected]> wrote: > >> Sorry about the delayed reply.... >> >> So, umm, how do you configure the environment variables then? Via >>> environment=... setting? You can't inherit it from supervisord's environment >>> as that would make all the processes share the values, defeating the point I >>> guess. How is that easier than configuring supervisord directly? Or am I >>> missing something? >> >> >> Well, they would be set in either the script that starts supervisord, or >> in our case, the script we "source" to set our environment variables in our >> dev environment which would be done before launching supervisord. >> >> So maybe you'd set >> export FOO_PORT=12415 >> export FOO_BASE_PATH=/tmp/1124 >> export CHEESE_PORT=13553 >> >> supervisord >> >> and in the config it would be like >> >> ... >> command=cheese -p %($CHEESE_PORT)s >> ... >> >> Could also use these variables for the port supervisord is running on >> which would make it possible to have completely isolated instances of >> supervisord + other software running on diff ports with the same config. >> Doing this with a templating language is cumbersome because you'd have to >> have a copy of the output of the templated configs for each instance you >> want to run. >> >> >>> While I'm using a template for my configs (jinja2 to be precise), I think >>> I'm against adding such a feature to supervisord core (not that I have any >>> say in this). I'd guess the requirements for more sophisticated config >>> handling vary from site to site so one size wouldn't fit all. Besides, I'm >>> quite happy with automatically (re)generating a config file and issuing a >>> supervisorctl update every now and then. One other lesson I learned was to >>> keep the process manager as simple as possible with limited responsibilities >>> and reasons for updates -- that's one daemon you don't want to restart >>> frequently. >> >> >> Yeah, adding it to the core would be a bad idea I feel as well. Perhaps >> something where you can add a hook for a preprocessor would be a nice >> compromise perhaps? >> >>> >>> >>> As an aside, I kinda wish supervisor was on github. Would make it >>>> much easier to contribute. >>>> >>> >>> It is now. Whee, about to rebase my repo :) >>> >>> Where at? :) >> >> Thanks, >> Mike >> >> _______________________________________________ >> Supervisor-users mailing list >> [email protected] >> http://lists.supervisord.org/mailman/listinfo/supervisor-users >> >> >
_______________________________________________ Supervisor-users mailing list [email protected] http://lists.supervisord.org/mailman/listinfo/supervisor-users
