Note: This discussion was imported from Loomio. Click here to view the original discussion.
Right now there are several ways to start Diaspora. Thin over script/server, with or without Resque depending on $RAILS_ENV, Thin over rails s, Unicorn directly, Unicorn with a bunch of Resque workers trough foreman, custom init scripts etc.
We should decide and recommend one method, ideally unified for development and production setups taking actions depending on configuration and/or $RAILS_ENV. Other people can still run their own but that should be banned from our resources and we should only allow one page linking to gists/blogs etc. for alternative methods but clearly stating that they are third party. And maybe one page describing how everything we start by the new method fits together.
Currently I think a way to go is to rewrite script/server to use foreman and to drop thin for unicorn completely. The benefit of foreman is that it is Heroku compatible and we could generate init scripts with it (but lets check back with packagers first for the quality of those).
Really, what’s the easiest way to start it up?
Well, since we require mutliple processes for operation, a process manager such as foreman or god seems ideal.
Everything else we can do ourselves will probably never reach the quality of those solutions.
Puma looks interesting, to say the least. It’d be interesting to see whether its speediness and low overhead could consequently improve pod performance, or at the very least, startup time.
I agree that defining a default startup method is useful, as it gives us one constant to be concerned about with starting up a pod deployment.
I think Jonne is right, we ought to document the current startup methods that have been commonly used with D*, not necessarily for the sake of documentation, but just to consider what our best options are.
From the Diaspora Podmin Survey that was released a while ago, the stats indicate that the most commonly used way of starting up a pod instance right now is the use of /script/server.
For interested parties, the survey results can be found here: https://docs.google.com/spreadsheet/ccc?key=0Apy1mX_Ls9oidFZNODQ5RFhMV3IwWlhjb0ZyeF9HVmc
Since it’s impossible to embed a resque worker into puma and we need that to run on Heroku on one dyno I switched script/server to foreman and dropped Thin for now. Once foreman has a systemd export (https://github.com/ddollar/foreman/issues/52) I’ll have a look on writing docs on how to generate initscripts using it.
Jonne, how does this change affect the ability to run a pod? (system/platform requirements etc) Is there a still valid reason Thin was used before?
Unifying startup methods would be great, as long as it doesn’t restrict how the software can be used.
Thin really is just a leftover from the early days afaik.
If no one can think of any reason to keep it then great - less supported stuff the better for architecture