From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.mongrel.devel Subject: Re: [ANN] Unicorn: UNIX+localhost/LAN-only Mongrel fork Date: Wed, 25 Feb 2009 21:55:44 -0800 Message-ID: <20090226055544.GA20153@dcvr.yhbt.net> References: <20090211230457.GB22926@dcvr.yhbt.net> <20090216233904.GB3198@dcvr.yhbt.net> <2A92C72C-498A-4A6E-9035-059CCF4C7371@gmail.com> <20090218004036.GA29439@dcvr.yhbt.net> <20090221151017.GA3788@untitled> <20090224010344.GG26706@dcvr.yhbt.net> <409638DC-A76B-40E1-AE5C-326F2573DACC@gmail.com> <20090224031223.GH26706@dcvr.yhbt.net> Reply-To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1235630187 10934 80.91.229.12 (26 Feb 2009 06:36:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 26 Feb 2009 06:36:27 +0000 (UTC) To: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Original-X-From: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Thu Feb 26 07:37:43 2009 Return-path: Envelope-to: gclrmd-mongrel-development@m.gmane.org Content-Disposition: inline In-Reply-To: <20090224031223.GH26706-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: mongrel-development-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: mongrel-development-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.mongrel.devel:98 Archived-At: Received: from rubyforge.org ([205.234.109.19]) by lo.gmane.org with esmtp (Exim 4.50) id 1LcZsH-0002La-3g for gclrmd-mongrel-development@m.gmane.org; Thu, 26 Feb 2009 07:37:37 +0100 Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 1711015B8020; Thu, 26 Feb 2009 01:36:13 -0500 (EST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by rubyforge.org (Postfix) with ESMTP id 1987C18580E2 for ; Thu, 26 Feb 2009 00:55:44 -0500 (EST) Received: from localhost (unknown [127.0.2.5]) by dcvr.yhbt.net (Postfix) with ESMTP id 2730C1F5FC; Thu, 26 Feb 2009 05:55:44 +0000 (UTC) List-Post: Eric Wong wrote: > Ezra Zygmuntowicz wrote: > > On Feb 23, 2009, at 5:03 PM, Eric Wong wrote: > >> Eric Wong wrote: > >>> Eric Wong wrote: > >>>> Ezra Zygmuntowicz wrote: > >>>>> Seems to work as advertised so far, cool stuff ;) One > >>>>> suggestion, folks > >>>>> are pretty standardized on rack and config.ru files these days. > >>>>> I'd much > >>>>> rather see unicorn look for a APP_ROOT/config.ru to load as its > >>>>> config > >>>>> file rather then the eval that returns a hash style it uses now. > >>>> > >>>> Ezra, thanks for testing and feedback. Good point about config.ru, > >>>> I'll try to make that change hopefully today to make it easier to > >>>> migrate from existing Rack apps. > >>> > >>> I just pushed out the following changes. > >>> > >>> * revamp configuration with Configurator DSL > >>> * Replace unicorn binary with something rackup-like > >>> * GNUMakefile: revamp for parallel 1.8/1.9 runs > >>> * test_exec: fix for temporary files not being cleaned > >>> * Fix+test reexec error handling on bad inputs > >> > >> > >> > >>> Basically the latest push includes config.ru compatibility and new > >>> test > >>> cases in test/exec/test_exec.rb for binary reexecution, listener > >>> inheritance, and reloading config files (even bad ones). > >>> > >>> This new config stuff is completely untested for any real apps and > >>> I'll > >>> need to update the examples soonish. But the new test cases pass in > >>> both 1.9.1 and 1.8.7, which is a good sign. > >> > >> Help... > >> > >> I'm basically a very confused person and I'm having trouble deciding > >> on > >> how/if config.ru should deal with the config file for Unicorn-specific > >> settings. Or if the Unicorn-specific config file should be allowed to > >> specify/override config.ru... > >> > >> Any ideas would be greatly appreciated, thanks! > > > > Eric- > > > > I'd say just make a small dsl or just configuration object for unicorn > > options and let people use the dsl/object in their config.ru files. > > Since config.ru is just ruby you can put any ruby code in there. Have > > folks put their unicron config code right at the top of config.ru. Will > > that work? > > The new Unicorn::Configurator object is pretty much that DSL. > > The main issue of handling config reloading (which should be "lighter" > than reexecuting the binary). Should/could that re-eval() the > Rack::Builder bits? How would I avoid that re-eval (without > dirtying the config up)[1]. > > Or should I handle reexecution as the only way to make config changes? > (I've strongly considered this, it's a very big hammer :) > > [1] - I don't feel completly comfortable with Unicorn-specific stuff in > config.ru, in case it makes it harder for people to try out and compare > their app on Mongrel/Thin/Ebb/Passenger/Glassfish/whatever... But I > suppose conditionals that check for defined?(Unicorn) can be enough... OK, here's some thoughts leading up to what I'm probably going to do... 1. APP_ROOT/config.ru is in a pretty standardized location, good. 2. Most config.ru files out there (probably) don't contain environment-specific logic. That is, developers on their desktop/laptops and the production app in datacenters can share the same config.ru without much difficulty. Can somebody please confirm this assumption? 3. Unicorn-specific config options should only be needed for server deployments. Things for the typical developer on their workstation should "just work", like running "script/server" and "mongrel_rails" in RAILS_ROOT does for old Rails apps. This leads me to keeping the Unicorn config file separate for production environments. My personal experience (with old Rails apps) is that there are multiple "production"-like environments (staging, QA, different datacenters)... I'd imagine some apps I support will end up with config file layouts looking like this: APP_ROOT/config/unicorn/prod_lax.rb APP_ROOT/config/unicorn/prod_dfw.rb APP_ROOT/config/unicorn/prod_nyc.rb APP_ROOT/config/unicorn/prod_chi.rb APP_ROOT/config/unicorn/qa.rb APP_ROOT/config/unicorn/staging.rb APP_ROOT/config/unicorn/demo.rb APP_ROOT/config.ru Thus to deploy to our Los Angeles datacenter, the script would just run: unicorn -c APP_ROOT/config/unicorn/prod_lax.rb If there's an APP_ROOT/config_prod.ru needed, then the APP_ROOT/config/prod_*.rb files would each be able to specify APP_ROOT/config_prod.ru instead of APP_ROOT/config.ru. That is, the Unicorn config file can specify an alternate config.ru, but config.ru cannot specify a different Unicorn config file. Am I making sense? (it's been a long week for me so far...) -- Eric Wong (no, I don't have YHBT.net running in 4 locations, yet :)