What I've learned deploying pylons

[jose]

HI all, Just thought I would share what I've learned deploying pylons
on both windows and linux loxes. First let me say right off the bat I
absolutely love pylons I think hands down its the absolutely best web
development environment out there. Having said that the biggest issue
I see with pylons and wsgi apps in general, really has nothing to do
with their ability to function as a framework, but its deployment.
Now before anyone goes all "read the wiki" "read the docs" on me, I
have so the rest of this is just my experience setting up pylons to
run with Apache on both windows and linux (Ubuntu specifically). Now
I love choices and if you want to connect your new pylons app to run
under apache you do have several, mod_wsgi, fastcgi, scgi, mod_python,
and the ever present mod_proxy, and I've tried them all. For my
money, both in terms of simplicity and in terms of development cycles
mod_proxy is by far the easiest and I would venture to say the most
stable. I did use mod_wsgi for a while, and will most likely use it
on a limited project where running a pylons long running appp will be
problematic, but mod_proxy just offers so much in the way of
flexibility. Not to mention the fact that I just hate restarting
apache just because I've made some minor change to one of my
controllers.

So this brings me to the heart of what I've learned, if you are going
to deploy a long running app how do you do it? On Windows the best
solution I've come up with is my own Bourbon project, which I admit
has all but died (I would love to give the code to someone to run
with, I just really don't have the time to maintain it any longer).
The reason I wrote it in the first place was allow give me a single
windows service to manage all my running pylons apps without having to
give each and every one its own windows service, which is a pain.
Bourbon works pretty good, but at the moment you can't turn off or
restart a single app, its all or nothing, which isn't very good.

On Linux its a different story, there are a tun of ways to get a long
running application up and running, and to some extent it depends on
what distro you are using as to which is the best. On ubuntu I
initially thought of writing rc init scripts for each app, but this
quickly turned into a task that I didn't want to deal with, so I
turned to mod_wsgi, which as I stated above for philosophical reasons
I just didn't like. The I found, ok more likely stumbled upon after
reading the wiki, supervisord. Finally something that makes sense (at
least to me it really does). Now, after writing only a single rc init
script to get supervisord running my pylons apps (and almost anything
else I might have to start as a a daemon for that matter) is easily
configured to run under the supervisord.conf file. I just love that
thing. I know a best practices section goes against the grain for the
pylons community because it is all about flexibility, but what about
a series of deployment scenario's, where people could write how they
are actually doing this stuff. I know its already all there if you
look for it, but this has taken me while to put together for myself
and I'm sure there are others out there who could learn from our
growing pains

[Mike Orr]

On Sat, Mar 28, 2009 at 4:42 PM, jose <jj.g...@gmail.com> wrote:
> So this brings me to the heart of what I've learned, if you are going
> to deploy a long running app how do you do it?

I put all my Pylons and Quixote apps under Supervisord, with Apache
mod_proxy. I want to try nginx when I have a chance.

Some people prefer mod_wsgi because it runs everything under Apache
processes, but I like being able to "supervisor stop" and "supervisor
start" individual applications for maintenance and debugging, plus
seeing them under their own names in the ps listing.

--
Mike Orr <slugg...@gmail.com>

[Noah Gift]

This recently came up at work, at one other gotcha is that you have to write your own init script.  Is there a recipe on the Pylons wiki for this?

 

--
Mike Orr <slugg...@gmail.com>

--
Cheers,

Noah

[Graham Dumpleton]

On Mar 29, 8:42 am, jose <jj.gal...@gmail.com> wrote:
> HI all, Just thought I would share what I've learned deploying pylons
> on both windows and linux loxes.  First let me say right off the bat I
> absolutely love pylons I think hands down its the absolutely best web
> development environment out there.  Having said that the biggest issue
> I see with pylons and wsgi apps in general, really has nothing to do
> with their ability to function as a framework,  but its deployment.
> Now before anyone goes all "read the wiki" "read the docs" on me, I
> have so the rest of this is just my experience setting up pylons to
> run with Apache on both windows and linux (Ubuntu specifically).  Now
> I love choices and if you want to connect your new pylons app to run

> under apache you do have several,mod_wsgi, fastcgi, scgi, mod_python,

> and the ever present mod_proxy, and I've tried them all.  For my
> money, both in terms of simplicity and in terms of development cycles
> mod_proxy is by far the easiest and I would venture to say the most

> stable.  I did usemod_wsgifor a while, and will most likely use it

> on a limited project where running a pylons long running appp will be
> problematic, but mod_proxy just offers so much in the way of
> flexibility. Not to mention the fact that I just hate restarting
> apache just because I've made some minor change to one of my
> controllers.

If you think you have to restart Apache whenever making changes you
haven't delved into the documentation for mod_wsgi well enough.

http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode

http://blog.dscpl.com.au/2008/12/using-modwsgi-when-developing-django.html
http://blog.dscpl.com.au/2009/02/source-code-reloading-with-modwsgi-on.html

Graham

> So this brings me to the heart of what I've learned, if you are going
> to deploy a long running app how do you do it?  On Windows the best
> solution I've come up with is my own Bourbon project, which I admit
> has all but died (I would love to give the code to someone to run
> with, I just really don't have the time to maintain it any longer).
> The reason I wrote it in the first place was allow give me a single
> windows service to manage all my running pylons apps without having to
> give each and every one its own windows service, which is a pain.
> Bourbon works pretty good, but at the moment you can't turn off or
> restart a single app, its all or nothing, which isn't very good.
>
> On Linux its a different story, there are a tun of ways to get a long
> running application up and running, and to some extent it depends on
> what distro you are using as to which is the best.  On ubuntu I
> initially thought of writing rc init scripts for each app, but this
> quickly turned into a task that I didn't want to deal with, so I

> turned tomod_wsgi, which as I stated above for philosophical reasons

[Graham Dumpleton]

On Mar 29, 11:05 am, Mike Orr <sluggos...@gmail.com> wrote:

> On Sat, Mar 28, 2009 at 4:42 PM, jose <jj.gal...@gmail.com> wrote:
> > So this brings me to the heart of what I've learned, if you are going
> > to deploy a long running app how do you do it?
>
> I put all my Pylons and Quixote apps under Supervisord, with Apache
> mod_proxy.  I want to try nginx when I have a chance.
>

> Some people prefermod_wsgibecause it runs everything under Apache

> processes, but I like being able to "supervisor stop" and "supervisor
> start" individual applications for maintenance and debugging,

One can use signals to mod_wsgi daemon mode processes to restart them,
as well as just touch the WSGI script file.

It is only when you want to add or remove a completely new mod_wsgi
daemon mode process that you need to 'restart' Apache after having
done suitable configuration change.

> plus seeing them under their own names in the ps listing.

The display-name option to WSGIDaemonProcess directive in mod_wsgi
daemon mode allows you to assign it a name which shows in 'ps' output.

Graham

[Jose Galvez]

Here is my supervisord init script.  not sure if its the best but its working

[Jose Galvez]

thanks for the pointers for mod_wsgi.  I will have to use it for a limited distribution project, but for general use I still like using paster with supervisord

[Wichert Akkerman]

You can do three things:

- start supervisord using init by adding an entry in /etc/inittab. This
requires root and is for the very paranoid: even if supervisord dies
(which never happens) it will be restarted.

- use an init script to start supervisord at system boot. Requires root.

- Start supervisord using an @reboot crontab entry in a normal account.
Does not require root. Works on all Linux distributions, I'm not sure
is other cron implementation support this.

The last one is my preferred method: it is trivial to setup and can be
done by any normal user.

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[Noah Gift]

thanks for the advice guys!  Will put to use on Monday. 

Wichert.

--
Wichert Akkerman <wic...@wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.

--
Cheers,

Noah

[Max Ischenko]

Hi jj,

On Sun, Mar 29, 2009 at 00:42, jose <jj.g...@gmail.com> wrote:

I can certainly sympathize here. ;)

I have tried various deployment solutions as well for my work on developers.org.ua project. I used to use supervisord plus mod_proxy + paster serve (cherrypy wsgi). To start supervisord on boot time I wrote simple /etc/event.d/supervisor script, I think I posted this solution to pylons wiki.

It worked nicely but then I discovered mod_wsgi and I was hooked. It was considerably simpler setup compared to superisor/paster/http_proxy. It run ok for about 4-5 months and then I switched deployment again. I had experienced strange Apache behaviour where it would cease to serve incoming requests even though on the surface everything seems just fine. I struggle for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault or something eniterly different.

Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead of supervisor (I already used it to monitor apache and other system resources and it was trivial task to add paster monitor checks). And I also set up nginx as a front-proxy.
And it all works amazingly good right now.

I run three identical paster servers which are proxied by nginx, using round-robin load balancing. nginx also serves all static content and works as a proxy to apache. Apache now has far fewer modules, mainly mod_php for our PHP pages.

See also http://unblog.developers.org.ua/2009/03/nginx.html

If you are interested I guess I could post relevant configs here or to Pylons wiki

--
Max.Ischenko // twitter.com/maxua

[Graham Dumpleton]

On Mar 29, 7:52 pm, Max Ischenko <ische...@gmail.com> wrote:
> Hi jj,
>

> On Sun, Mar 29, 2009 at 00:42, jose <jj.gal...@gmail.com> wrote:
>
> I can certainly sympathize here. ;)
>
> I have tried various deployment solutions as well for my work on
> developers.org.ua project. I used to use supervisord plus mod_proxy + paster
> serve (cherrypy wsgi). To start supervisord on boot time I wrote simple
> /etc/event.d/supervisor script, I think I posted this solution to pylons
> wiki.
>
> It worked nicely but then I discovered mod_wsgi and I was hooked. It was
> considerably simpler setup compared to superisor/paster/http_proxy. It run
> ok for about 4-5 months and then I switched deployment again. I had
> experienced strange Apache behaviour where it would cease to serve incoming
> requests even though on the surface everything seems just fine. I struggle
> for a couple of weeks and then gave up. I am not sure it was mod_wsgi fault
> or something eniterly different.

Don't know if that was related to zombie issue you asked about on
mod_wsgi list back in November or not. You were asked to supply some
more specific information but you never responded. Bit hard to solve
what ever problem it was when you don't followup about it. -(

Anyway, all indications suggest it was something about your specific
application, environment or configuration, as no general problem with
mod_wsgi has come up which would explain such behaviour and no one
else has reported anything like it.

I do find though that a lot of problems people have are because they
use embedded mode, especially with prefork, and do not bother to
properly configure the Apache MPM settings to appropriate values for
fat Python web applications. I have blogged about this previously in
relation to mod_python, but also relevant to mod_wsgi embedded mode.

http://blog.dscpl.com.au/2009/03/load-spikes-and-excessive-memory-usage.html

Graham

> Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead
> of supervisor (I already used it to monitor apache and other system
> resources and it was trivial task to add paster monitor checks). And I also
> set up nginx as a front-proxy.
> And it all works amazingly good right now.
>
> I run three identical paster servers which are proxied by nginx, using
> round-robin load balancing. nginx also serves all static content and works
> as a proxy to apache. Apache now has far fewer modules, mainly mod_php for
> our PHP pages.
>

> See alsohttp://unblog.developers.org.ua/2009/03/nginx.html

[Noah Gift]

To be honest, I am a pretty big fan of Apache, and I have used mod_wsgi with success.  Finding out about how to automatically reload apps is a nice find.  I agree that when I am developing, I want to run on the actual server that will be running my code in production.  It sounds like someone needs to write the definitive guide to mod_wsgi :)  I would read it.... 

 

Graham

> Anyway, I switched back to paster (cherrypy WSGI) but I used monit instead
> of supervisor (I already used it to monitor apache and other system
> resources and it was trivial task to add paster monitor checks). And I also
> set up nginx as a front-proxy.
> And it all works amazingly good right now.
>
> I run three identical paster servers which are proxied by nginx, using
> round-robin load balancing. nginx also serves all static content and works
> as a proxy to apache. Apache now has far fewer modules, mainly mod_php for
> our PHP pages.
>

> See alsohttp://unblog.developers.org.ua/2009/03/nginx.html

>
> If you are interested I guess I could post relevant configs here or to
> Pylons wiki
>
> --
> Max.Ischenko // twitter.com/maxua

--
Cheers,

Noah

[Max Ischenko]

On Sun, Mar 29, 2009 at 12:35, Graham Dumpleton <Graham.D...@gmail.com> wrote:

Don't know if that was related to zombie issue you asked about on
mod_wsgi list back in November or not. You were asked to supply some
more specific information but you never responded. Bit hard to solve
what ever problem it was when you don't followup about it. -(

You're absolutely right of course. I should have troubleshooted it better. I am 99% sure it's not mod_wsgi fault.
After all, even now it leaks memory like there is no tomorrow so monit have to restart it about once in 4-6 days.

The thing is, I am not such a great programmer, I don't have tons of admin expertise (nor I am too keen to get it) and there are pressing concerns (as always) such as site being not available to users. I was looking  for the easiest/fastest route possible and nginx/http proxy worked for me.

PS: as for automatic code reloading, we did used it, on production too. May be we shouldn't be.

[Mike Orr]

On 3/28/09, Jose Galvez <jj.g...@gmail.com> wrote:
> Here is my supervisord init script. not sure if its the best but its
> working

This script looks like it's for Red Hat; here's one for Ubuntu. Start
works and stop works, but restart doesn't for some reason, so I have
to start it again after restarting.

As for supervisord spontaneously crashing and needing to be
relaunched; I've never seen it happen.

By the way, the easiest way to make an init script is to copy an
existing minimal one.

===
#! /bin/bash -e

# /etc/init.d/supervisor: start and stop the Supervisor daemon manager

#SUPERVISORD=/usr/local/bin/supervisord
#SUPERVISORCTL=/usr/local/bin/supervisorctl

SUPERVISORD=/usr/local/venv-supervisor/bin/supervisord
SUPERVISORCTL=/usr/local/venv-supervisor/bin/supervisorctl
PIDFILE=/var/run/supervisord.pid
OPTS="-c /etc/supervisord.conf"

test -x $SUPERVISORD || exit 0

. /lib/lsb/init-functions

export PATH="${PATH:+$PATH:}/usr/local/bin:/usr/sbin:/sbin"

start () {
log_begin_msg "Starting Supervisor daemon manager..."
$SUPERVISORD $OPTS || log_end_msg 1
log_end_msg 0
}

stop () {
log_begin_msg "Stopping Supervisor daemon manager..."
$SUPERVISORCTL shutdown || log_end_msg 1
log_end_msg 0
}

case "$1" in
start)
start
;;

stop)
stop
;;

restart|reload|force-reload)
stop
start
;;

esac

exit 0
===

--
Mike Orr <slugg...@gmail.com>

[Max Ischenko]

On Sun, Mar 29, 2009 at 16:55, Mike Orr <slugg...@gmail.com> wrote:

On 3/28/09, Jose Galvez <jj.g...@gmail.com> wrote:
> Here is my supervisord init script.  not sure if its the best but its
> working

This script looks like it's for Red Hat; here's one for Ubuntu.  Start
works and stop works, but restart doesn't for some reason, so I have
to start it again after restarting.

If you're using Ubuntu, I'd suggest using their newer upstartn system.

Here is my /etc/event.d/supervisor script

"""
exec supervisord --nodaemon

start on runlevel 2
console output
"""

That's it. Worked quite nicely.  For more info see http://upstart.ubuntu.com/getting-started.html

And if you want to monitor the supervisord and restart if it fails (never happened to me) I can recommend monit, available via apt-get.

Max.

[Jose Galvez]

That would be great I would love to the configs
Jose

[Jose Galvez]

so is upstartn going to replace System V eventually? 

[Jose Galvez]

Wow this discussion has been really great, I've learned quite a bit just
following the different threads. Like I said I think there is room in
the wiki for us to post better real world howto's with end to end config
files. For example I could post my:
1) init script for supervisord (although I think the one Mike posted is
better then mine so I'll most likely edit mine
2) the section in my supervisord.conf file
3) the sections in my apache conf files

I would like to see the same thing from Max on how he did it with nginx
and monit, and how Graham is serving his stuff with mod_wsgi. As
mentioned in one of the posts mod_wsgi could use some better
documentation and this might be a good way to do that.

Max also mentions upstartn, whats the advantage to that over using the
system V script?

Jose

[Graham Dumpleton]

On Mar 30, 7:17 am, Jose Galvez <jj.gal...@gmail.com> wrote:
> Wow this discussion has been really great, I've learned quite a bit just
> following the different threads.  Like I said I think there is room in
> the wiki for us to post better real world howto's with end to end config
> files.  For example I could post my:
> 1) init script for supervisord (although I think the one Mike posted is
> better then mine so I'll most likely edit mine
> 2) the section in my supervisord.conf file
> 3) the sections in my apache conf files
>
> I would like to see the same thing from Max on how he did it with nginx
> and monit, and how Graham is serving his stuff with mod_wsgi.  As
> mentioned in one of the posts mod_wsgi could use some better
> documentation and this might be a good way to do that.

Do you mean better mod_wsgi documentation as part of the Pylons
documentation, or that mod_wsgi itself needs better/more
documentation?

There is already quite a lot of documentation on mod_wsgi. It could be
a bit better indexed but if one follows the main entry points from the
mod_wsgi main page, it will get you to most stuff.

http://code.google.com/p/modwsgi/wiki/InstallationInstructions
http://code.google.com/p/modwsgi/wiki/DeveloperGuidelines

The index of everything is at:

http://code.google.com/p/modwsgi/w/list

The main ones pertinent to Pylons are:

http://code.google.com/p/modwsgi/wiki/IntegrationWithPylons
http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

There is also some information in the online Pylons book, although
that does have at least one mistake in claiming that EvalException
cannot be used with mod_wsgi. You just need to make sure you are
running daemon mode with a single process. That is also mentioned in
documentation:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Browser_Based_Debugger

Graham

[Jose Galvez]

Graham Dumpleton wrote:

On Mar 30, 7:17 am, Jose Galvez <jj.gal...@gmail.com> wrote:
  

Wow this discussion has been really great, I've learned quite a bit just
following the different threads.  Like I said I think there is room in
the wiki for us to post better real world howto's with end to end config
files.  For example I could post my:
1) init script for supervisord (although I think the one Mike posted is
better then mine so I'll most likely edit mine
2) the section in my supervisord.conf file
3) the sections in my apache conf files

I would like to see the same thing from Max on how he did it with nginx
and monit, and how Graham is serving his stuff with mod_wsgi.  As
mentioned in one of the posts mod_wsgi could use some better
documentation and this might be a good way to do that.
    

Do you mean better mod_wsgi documentation as part of the Pylons
documentation, or that mod_wsgi itself needs better/more
documentation?
  

I guess I mean better or more complete example is probably a better choice of words rather then documentation because as you already mentioned mod_wsgi has good docs

[Jonathan Vanasco]

On Mar 29, 4:52 am, Max Ischenko <ische...@gmail.com> wrote:

> I run three identical paster servers which are proxied by nginx, using
> round-robin load balancing. nginx also serves all static content and works
> as a proxy to apache. Apache now has far fewer modules, mainly mod_php for
> our PHP pages.

FWIW, I found a considerable performance upgrade over Apache's mod_php
by switching to php-cgi through nginx, and then running an opcode
cache ( either APC or eAccelerator ) made it even faster. There are
some benchmarks out there on this; unless you need something within
apache itself ( i often do for mod_perl ) , it might be worth
discarding completely.

[Arun Tomar]

hi!

well quite a discussion. just to add & share my experience of
developing on pylons & deploying it.

My requirement was to host multiple pylons application, on a single
server. so running each app on paster daemon & proxy to it via either
apache or nginx was not a very optimal solution for me.

So i tried using apache 2+ mod_wsgi, which is good & works well, but
it's a bit slow for now. i hope that in future it's performance will
increase more.

Then i tried nginx+mod_wsgi, which is great in terms of performance,
speed & scalability. You can just keep on adding different pylons
webapps as virtual hosts to nginx & everything works. so far it has
been great.

Our product is a website management system, ( you can say a CMS sort
of app ). I"ve deployed the nginx + mod_wsgi on our new VPS, and will
be going live any day.

--
Regards,
Arun Tomar
blog: http://linuxguy.in
website: http://www.solutionenterprises.co.in

[Jared Rhine]

On 03/29/2009 01:17 PM, Jose Galvez wrote:
> Max also mentions upstartn, whats the advantage to that over using the
> system V script?

Two advantages are obvious: automatic restart and a dramatically
shorter amount of config needed to get running.

While supervisord, monit, etc seems to be more popular, I've been
using "runit" everywhere for years and have succeeded in converting a
number of people to its use. runit is basically an open-source,
maintained version of DJB's daemontools. daemontools I guess is open-
source now, but DJB's previous "can't distribute this code if it has
been modified" killed it as a viable project.

runit's configuration looks much more like upstart than supervisord;
here's one of my production pylons runit start scripts:

-----

#!/bin/sh



exec 2>&1

PY=/usr/local/python
export PYTHONPATH=$PY/lib/python2.5/site-packages

cd /home/tsm
exec chpst -u tsm:tsm $PY/bin/paster serve --reload tsm-prod.ini

-----

Another start script:

-----

#!/bin/sh
exec 2>&1
exec chpst -u bots:bots -/ /home/eggdrop ./eggrop -n ./eggdrop.conf

-----

(The "exec 2>&1" is to capture stderr output; runit arranges to
capture all stdout of the program and put it into automatically-
rotated log files. upstart can do basically the same using "upstart-
logd".)

I like runit over upstart, even where upstart is available because 1)
it's available on all unixes and already in most distro package
managers; 2) it uses just scripts and files, not a custom config
language for dependencies/pre-start/post-stop scripts; 3) by default,
it doesn't replace init(1), just adds itself to init. But I would use
upstart probably if it was easily available everywhere I admined.

Near as I can see, upstart is a reimplementation of ideas long ago
nailed by daemontools and runit, but with a need to back-support SysV
runlevels, a custom config language (instead of some specific
conventions), more direct support for service dependencies, and some
Ubuntu specifics.

Someone asked if upstart was going to replace SysV startup (at least
on ubuntu). That's their intent; I dunno how successful they will be.
I've had no problems mixing and matching "startup/supervision"
systems, so I don't see a real need for it to be "either/or". I have
many servers with a variety of supervision systems; I tend not to
place Apache under runit (it's easy) because Apache works fine out of
the box on Debian and I haven't had Apache die on me in probably a
decade.

In general, I like all the "run in foreground" approaches (runit,
daemontools, upstart, supervisord). It's just safer to assume each
layer will die eventually, and arrange for there to be direct
supervision all the way back to init(1). @reboot techniques make me
nervous, though that's also a handy approach.

Note that it's a really good idea to actual monitor the resulting
service, not just the process id. In this way, monit (or nagios/
whatever) configured to monitor the actual HTTP port and try a restart
if that fails is more reliable than just "restart if the process
dies". This is because it's possible for the web app process to be
running, but something has broken (database connection, permissions,
etc) that keeps it from actually serving HTTP.

I might use a great solution like ngnix+mod_wsgi in production for
great performance, but it'd end up having ngnix monitored by runit.

-- Jared

[Graham Dumpleton]

On Mar 30, 10:56 pm, Arun Tomar <tomar.a...@gmail.com> wrote:
> hi!
>
> well quite a discussion. just to add & share my experience of
> developing on pylons & deploying it.
>
> My requirement was to host multiple pylons application, on a single
> server. so running each app on paster daemon & proxy to it via either
> apache or nginx was not a very optimal solution for me.
>
> So i tried using apache 2+ mod_wsgi, which is good & works well, but
> it's a bit slow for now. i hope that in future it's performance will
> increase more.

Apache/mod_wsgi performance with a typical Python web application
should not be much different to other solutions.

The mistake people often make in comparing it to others is that they
don't take into consideration when benchmarking it that Apache/
mod_wsgi performs lazy loading where as others will often preload the
application. Not realising this and factoring it into how you run your
benchmarks, and/or not configuring Apache/mod_wsgi to preload the
application can really screw up your results and give the impression
that Apache/mod_wsgi performs poorly.

If you have any remaining interest in Apache/mod_wsgi, you may perhaps
want to go over to the mod_wsgi list and can review how you were
actually setting up your system and performing the benchmarking and
work out why you were seeing sub optimal performance. Even if there
were an issue in Apache/mod_wsgi, things will never improve if you
never feedback information about problems you may have encountered.

Graham

[Wyatt Baldwin]

On Mar 28, 11:50 pm, Wichert Akkerman <wich...@wiggy.net> wrote:
> Previously Noah Gift wrote:

> > On Sun, Mar 29, 2009 at 1:05 PM, Mike Orr <sluggos...@gmail.com> wrote:

>
> > > On Sat, Mar 28, 2009 at 4:42 PM, jose <jj.gal...@gmail.com> wrote:
> > > > So this brings me to the heart of what I've learned, if you are going
> > > > to deploy a long running app how do you do it?
>
> > > I put all my Pylons and Quixote apps under Supervisord, with Apache
> > > mod_proxy.  I want to try nginx when I have a chance.
>
> > > Some people prefer mod_wsgi because it runs everything under Apache
> > > processes, but I like being able to "supervisor stop" and "supervisor
> > > start" individual applications for maintenance and debugging, plus
> > > seeing them under their own names in the ps listing.
>
> > This recently came up at work, at one other gotcha is that you have to write
> > your own init script.  Is there a recipe on the Pylons wiki for this?
>
> You can do three things:
>
> - start supervisord using init by adding an entry in /etc/inittab. This
>   requires root and is for the very paranoid: even if supervisord dies
>   (which never happens) it will be restarted.
>
> - use an init script to start supervisord at system boot. Requires root.
>
> - Start supervisord using an @reboot crontab entry in a normal account.
>   Does not require root. Works on all Linux distributions, I'm not sure
>   is other cron implementation support this.
>
> The last one is my preferred method: it is trivial to setup and can be
> done by any normal user.

Well, I went and got all excited about supervisor, then learned that
it doesn't support Python 2.6 very well and may never[1] (although it
does seem to work to some extent in my setup with Python 2.6.1). I
also noticed that the last 3.0 alpha release was over a year ago.

Questions: Which versions of supervisor and Python are ya'll using
together? Should I go for supervisor 2.1 or 2.2b1 or 3.0a6 or ...?

Currently, there's nothing I'm really using from Python 2.6 and
switching back to 2.5 wouldn't be a big problem, but it would be nice
to be able to move to it in the future.

[1] http://lists.supervisord.org/pipermail/supervisor-users/2009-March/000312.html

[Wichert Akkerman]

Previously Wyatt Baldwin wrote:
> Questions: Which versions of supervisor and Python are ya'll using
> together? Should I go for supervisor 2.1 or 2.2b1 or 3.0a6 or ...?

Everyone is running 3.0a6 as far as I know.

[Wyatt Baldwin]

On Mar 30, 11:08 pm, Wichert Akkerman <wich...@wiggy.net> wrote:
> Previously Wyatt Baldwin wrote:
> > Questions: Which versions of supervisor and Python are ya'll using
> > together? Should I go for supervisor 2.1 or 2.2b1 or 3.0a6 or ...?
>
> Everyone is running 3.0a6 as far as I know.

Anybody using it with Python 2.6 or have plans to?

[Jose Galvez]

Well I sure hope it works with 2.6, I just started using it (upgraded to the development svs version as the production version is about a year old) and love it.  So I guess I'll be giving it a try on 2.6 as soon as Jaunty (Ubuntu 9.04) comes out at the end of the month as 2.6 will finally be the default version of python in Ubuntu with the new release

[Wyatt Baldwin]

> On Tue, Mar 31, 2009 at 9:44 AM, Wyatt Baldwin

> <wyatt.lee.bald...@gmail.com>wrote:

>
>
>
> > On Mar 30, 11:08 pm, Wichert Akkerman <wich...@wiggy.net> wrote:
> > > Previously Wyatt Baldwin wrote:
> > > > Questions: Which versions of supervisor and Python are ya'll using
> > > > together? Should I go for supervisor 2.1 or 2.2b1 or 3.0a6 or ...?
>
> > > Everyone is running 3.0a6 as far as I know.
>
> > Anybody using it with Python 2.6 or have plans to?
>

On Apr 6, 5:29 pm, Jose Galvez <jj.gal...@gmail.com> wrote:
> Well I sure hope it works with 2.6, I just started using it (upgraded to the
> development svs version as the production version is about a year old) and
> love it. So I guess I'll be giving it a try on 2.6 as soon as Jaunty
> (Ubuntu 9.04) comes out at the end of the month as 2.6 will finally be the
> default version of python in Ubuntu with the new release

It *seems* to work with 2.6, but it throws out an error when starting
or stopping a service/app. That makes me nervous for something that's
supposed to be monitoring critical apps. For now, I've installed
Python 2.5 just to run supervisor, while running my apps on 2.6. BTW,
my research indicates that the problem is not with supervisor directly
but rather with some sort of API breakage in asyncore (and/or
asynchat) in Python 2.6.

[Iain Duncan]

> > Do you mean better mod_wsgi documentation as part of the Pylons
> > documentation, or that mod_wsgi itself needs better/more
> > documentation?
> >
> I guess I mean better or more complete example is probably a better choice of words rather then documentation because as you already mentioned mod_wsgi has good docs

I second that. I think Graham has written a ton of good stuff and has
provided first rate support on mailing lists, but ... for cases where
the user reading is not nears as experienced as the author, the docs are
a bit overwhelming technically. I've found that when I'm wading through
stuff that's over my head, lots of simple examples are my favourite bit,
even if they seem redundant and pedantic to the author. Rest assured,
someone needs them! ;-)

Iain

[Jose Galvez]

well if supervisord is not supported in python2.6 then I may have to switch to something else which would be a real bummer I really liked the way supervisor does things.  In any event I think I'll take a look at runit just to get acquainted with it
Jose

[Ian Bicking]

On Wed, Apr 8, 2009 at 12:32 AM, Jose Galvez <jj.g...@gmail.com> wrote:

well if supervisord is not supported in python2.6 then I may have to switch to something else which would be a real bummer I really liked the way supervisor does things.  In any event I think I'll take a look at runit just to get acquainted with it

There's no reason supervisor has to run with the same Python as you use for your applications.  So long as you have python2.5 installed somewhere you can still use it.

--
Ian Bicking  |  http://blog.ianbicking.org