On Wed, 2010-12-08 at 11:42 +0100, Grzegorz Nosek wrote:
> Hi,
> 
> (this mail only reached me moments ago, along with several others even 
> older from supervisor-users@, strange)

It's because Mike sent it to the list without being subscribed and I
pulled it out of the rejection queue.

- C


> 
> W dniu 02.12.2010 22:07, Mike Lewis pisze:
> > Hi,
> >
> > I have been considering using supervisord for our local dev
> > environments here instead of a custom rolled solution that we've had
> > in place.  The thing that is holding me back right now is that we have
> > custom ports for all the processes we launch because we make it so we
> > can have multiple instances of the environments being run.
> 
> This kind of matches our production environment (a few "template" 
> configs, running on all kinds of sockets and ports under different users.)
> 
> > It seems like there's no way to easily have "dynamic" configuration
> > files right now, however I feel it would not be too hard to add
> > support.
> >
> > One proposal I have is to allow reference to environment variables by
> > letting expansions like %($ENV_VAR)s be valid.
> 
> 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?
> 
> > It's a fairly trivial change to make (hacked together patch attached).
> >
> > The other thing that may be cool is allowing for preprocessing of
> > config files with a templating langauge.
> 
> 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.
> 
> > 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 :)
> 
> Best regards,
>   Grzegorz Nosek
> _______________________________________________
> 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

Reply via email to