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
