

Graceful reloading with zero downtime for web apps - teleyinex
http://daniellombrana.es/blog/2015/07/01/the-art-of-graceful-reloading.html

======
calpaterson
> The documentation from uWSGI is really great

I don't think the documentation is really great. I think it is terrible. Every
page seems to assume you understand the internals and the documentation
attaches fancy names to concepts that are difficult to understand from the
documentation.

For example, "workers' mercy", "zerg mode", "emperor mode", "the zeeg
problem", "uwsgi mules", "harakiri mode".

I for one would like uwsgi a lot more if it focused on a few simple patterns
that worked for the majority of cases and explained them thoroughly, including
their tradeoffs.

~~~
wisty
Sounds like Twisted all over again. A powerful framework with a steep learning
curve.

~~~
papercruncher
Sort of. You can definitely be up and running relatively easily, it's just
there are so many different knobs and switches and ways to set things up, you
never know if you are doing things the right way. I also agree that the
documentation is not particularly helpful and sometimes it's contradictory.
The software itself is rock solid though, gives me very little trouble (other
than logrotate & emperor mode being a pain)

~~~
calpaterson
It's theoretically rock solid. In practice there are many common scenarios
where uwsgi goes wrong. Here's one where a seemingly normal configuration of
supervisor and uwsgi doesn't work because uwsgi attached a special meaning to
SIGTERM

[https://github.com/unbit/uwsgi/issues/296](https://github.com/unbit/uwsgi/issues/296)

Note that the bug is closed because it will be fixed in an as-yet unreleased
version!

~~~
teleyinex
Yes, you are right. But, IMHO the solution is really simple. In your
supervisor config you ony add this option and everything works as expected:

stopsignal=QUIT

We're using it and no problems so far. Simple!

~~~
calpaterson
Read the thread I linked - multiple commenters say that using SIGQUIT does not
solve the problem for them and eventually unbit states that he recommends
using --die-on-term.

You are using the wrong workaround, so if you haven't had problems yet, it
could only be a matter of time.

And this is only one aspect of uwsgi that is buggy/unclear

~~~
teleyinex
Thanks! I'll have a look again :-)

------
eli
Adding a zerg server still feels a little like adding another layer to my
stack. Or do I misunderstand? I guess it's not literally a new package to
install, but it definitely feels like one more thing that can go sideways.

~~~
teleyinex
Hi,

Not really. That's why we love so much uwsgi. All you have to do is to add a
new config file for your zerg server, and you are done. This is handled
without problems by supervisor and we've never experienced an issue with it.

I've another blog post about our full infrastructure, explaining specifically
why we love uwsgi + supervisor. Because we don't need extra software within
our stack and everything is pretty simple and runs on Python :D

~~~
eli
But I'm not running a zerg server right now (I don't think!) so it would be a
new daemon even if it's part of an existing package, right?

Looking forward to more blog posts. Uwsgi is new to me, but so far I've been
very pleased with it.

I've been considering solving deploys at a higher level by spinning up a new
docker container and moving traffic from one to the other.

~~~
teleyinex
You only have to add a new daemon/process. Then you'll have this graceful
reloading feature ;-) From my point of view is has less impact than booting a
new container.

------
tempodox
That visual effect when hovering over a link is really bad.

