Make uwsgi the default web server in Galaxy II#2802
Make uwsgi the default web server in Galaxy II#2802jmchilton wants to merge 11 commits intogalaxyproject:devfrom
Conversation
All of the common startup stuff is still there. Compatibility with previous paster supported options is provided with the exception of --reload which is dangerous. This will look for uwsgi in the .venv, and if not found look for it on the PATH.
…e more of the stack. http-raw-body is enough to make websockets work (chunk input).
Conflicts: lib/galaxy/config.py run.sh
Possibly the most widely hated thing I ever added to Galaxy?
|
@erasche are you okay in the abstract with this removing the go proxy work. Even if the go proxy has some nice features and deployment ease the nodejs one didn't - hopefully this approach will lead to an even easier deployment and even more integrated options in terms of programming timeouts, etc... |
@jmchilton 100% ok. Have been from the start. Just wanted to spur people to make some progress towards GIE goals. completely uWSGI is absolutely the way to go, IMO. |
|
@erasche Awesome sauce - thanks! |
|
@jmchilton I brought the removal of Paste thing up with @jxtx at the GCC and agree that it should be a gradual transition rather than ripped out (and uWSGI for new). |
|
I'm fine with a gradual transition, as long as there is a transition and we reach a point where we can assume uWSGI only. While this currently only effects some "optional" type features, once we have websockets we will want to use them in many core parts of the application (e.g. History updates). |
|
Closing this for now - I think we need to resolve the remaining issues for uwsgi discovered in #3179 and merge that PR before proceeding with Galaxy. |
Continuation of work started by @jxtx on #2557 and #2385.
I guess to critique the original PR - I'd sort of like to see a softer transition. This requires everyone to update their galaxy.ini file if they are using run.sh. I think I would like to see the paster options restored to run.sh and that file just dispatch on the contents of the ini file and launch either server (and uwsgi for new installs).
Certain functionality will only be available in uwsgi - such as IE proxies - but this is fine for now. Until we have a compelling use of web sockets that doesn't degrade cleanly I don't know that we should make upgrades harder than they need to be?
If we don't agree on the above point - then I think it would be best to merge this as part of @natefoo's work at a new install method. We shouldn't have two such difficult updates in one year I don't think.