Hi Christian, On Sun, 2009-04-19 at 21:26 +0200, Christian Hofstaedtler wrote: > Integrating rack nicely has multiple aspects, and I seek input on > all of them: > > * Passenger (AKA mod_rails for Apache) shall again be supported > (see wiki:UsingPassenger). Passenger obviously expects rack applications > to completely follow the rack specification, including the need for > a "config.ru" file which contains the application startup code.
OK. > For 0.24.6 we had an ext/passenger/config.ru, which mostly consisted > of copy-pasted code from bin/puppetmasterd. This is clearly not > ideal, as it has to be maintained seperately and can't be tested > easily. Yes, that's not ideal. > Also, some Puppet code assumes, that the puppetmaster process is > named puppetmasterd. This is problematic ($0 will usually be "Rack" > or something). I _think_ that only Settings uses $0. This is work-aroundable easily in the "rack" application by setting Puppet.settings[:name] = "puppetmasterd". If it's done at the right place it works fine (I did it in puppetdoc and puppetclean, which I should resurrect from the dead one day). > Right now, I've Passenger working, with a 3-line config.ru + > http://github.com/zeha/puppet-rack/blob/340d21f80b4cc0b786b259ccac091adce02f3fb6/lib/puppet/network/http/rack_server.rb > > I can't think of a good place where to put this code; or how this > and lib/puppet/application/puppetmasterd could be unified, without > causing too much complexity. Can't you put that code in lib/puppet/application/puppetmasterd and define an option (obviously --rack or --server rack). Then if you get this option you route the app to execute: > # Fire up the Rack-Server instance > server = Puppet::Network::HTTPServer::Rack.new(handlers) > > # prepare the rack app > app = proc do |env| > server.process(env) > end > > # Go. > run app Instead of what was doing the puppetmasterd usually. Then, your config.ru would just be (warning pseudo-code): require 'application/puppetmasterd' ARGV << "--rack" Application[:puppetmasterd].run Let me know if I'm plain wrong. > * Using rack inside Mongrel: > > With the same config.ru + rack_server.rb I can successfully host > puppetmaster inside mongrel, by doing something like this: > for port in `seq 18140 18150`; do > rackup --server mongrel --port $port & > done > > (rackup is a rack application runner included in the 'rack' gem.) Definitely cool. > * Using rack with WEBrick: > > This is a completely thingy, because: > - WEBrick is the default server for puppetmasterd; > - Starting bin/puppetmasterd should just work (SSL etc) > - puppetd listen mode also uses WEBrick > - Rack::Handler::WEBrick usually is only ran by rackup, therefore > it assumes a few things, like trapping SIGINT for proper shutdown. > > Yes, it can be done, but care must be taken. > My initial, very trivial attempt (see URL below) breaks a lot of > tests and other stuff, but nevertheless seems to support a working > client-serving puppetmaster. > http://github.com/zeha/puppet-rack/commit/bae848f2b8ff9c7291f376140559de25fb37ae3c I think we must still support WebRick directly because we can't have a dependency on Rack for puppetd. So the webrick code should be kept as is. But other than that, I think you're on the right track. -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
