Wow this looks very elegant. I had no clue that this is possible.
Do we plan to switch to uwsgi for 16.07?

@jxtx the golang proxy was intended to solve deployment / config issues, but this is very interesting as well. We have some plans for the GIE stuff that you should be aware of while adding another proxy in the mix, namely #2085.

1. We use uwsgi for Galaxy main. With this configuration we can proxy directly to interactive environments, no double proxy needed.
2. We've talked about making uwsgi the default webserver for all Galaxy's. If we do that we can proxy directly without needing additional processes or ports.

I'm not seeing 1/2 in the current code? Do you have plans here?

1. uwsgi is fast, flexible, and well tested.

No contest.

1. I was having trouble getting the node based proxy running.

Yep. Huge part of my motivation for golang proxy which was a fast, efficient, single binary to drop in and provide GIE proxying.

@bgruening I don't have the code to make a case for it yet, but I think switching to uwsgi makes a lot of sense. It would give us a way to start introducing websockets into Galaxy itself.

@erasche

the golang proxy was intended to solve deployment / config issues

Yes, I had read that thread. I thought I would give this a try and it worked better than I expected. I appreciate what you've done with the golang proxy, but I have some concerns similar to what @jmchilton expressed in that issue. I'm not fond of golang and if we don't need to introduce it into Galaxy I would prefer not to. This solution is much simpler than either of the existing proxies in terms of code and configuration, but leverages uwsgi so it has a lot of flexibility. I think this may be a better way to go for the way to do dynamic proxies in Galaxy.

We use uwsgi for Galaxy main. With this configuration we can proxy directly to interactive environments, no double proxy needed.
We've talked about making uwsgi the default webserver for all Galaxy's. If we do that we can proxy directly without needing additional processes or ports.
I'm not seeing 1/2 in the current code? Do you have plans here?

So 1 is just configuration, no code to show. Add something similar to what is in uswgi_proxy.ini to your uwsgi config for Galaxy, set Galaxy not to manage the proxy, and things will just work.

For 2 I don't have code yet, but I'll try to get something together.

Yes, I had read that thread. I thought I would give this a try and it worked better than I expected. I appreciate what you've done with the golang proxy, but I have some concerns similar to what @jmchilton expressed in that issue. I'm not fond of golang and if we don't need to introduce it into Galaxy I would prefer not to. This solution is much simpler than either of the existing proxies in terms of code and configuration, but leverages uwsgi so it has a lot of flexibility. I think this may be a better way to go for the way to do dynamic proxies in Galaxy.

I don't disagree with any of this. I was just using the tools I knew were available at the time. When we were looking at moving container launching + killing into the proxy, it made a lot more sense. Docker is written in it, a proxy written in it exposing an HTTP api wouldn't be a bad thing.

I'm 100% on board with scrapping my work if it's going to be as simple as this leads me to believe. :)

So 1 is just configuration, no code to show

I was referring more to

With this configuration we can proxy directly to interactive environments, no double proxy needed

since you were launching a separate process, hence grouping it with 2. That's all.

Thanks for the feedback!

Thanks for starting the process on this @jxtx - I did look at uwsgi (and a few other Python options) for a long time before starting work on the javascript solution but I couldn't get it work. If uwsgi provides a path forward that allows us to just dynamically manage proxies from within the Galaxy process - so many limitations or complications due to configuration options, cookies, timeouts, etc... would be minimized to an amazing degree - but even if it is just a separate Python process that still makes dependencies easier at least and this implementation is obviously very clean.

Thanks @jmchilton. My plan is to propose making uwsgi the default web process, and then implement proxying there. What I'm not sure about is whether this PR should be merged or if we should just wait for than and then get rid of proxy entirely.

@jxtx I think it's fine to merge this if the intention is to get uwsgi as the default web process for the next release. This would help testing the proxy for those that have uwsgi already running.

This is marked as WIP so I am pushing it to 18.05.