Brice, * Brice Figureau <[email protected]> [090420 10:56]: > On Sun, 2009-04-19 at 21:26 +0200, Christian Hofstaedtler wrote: > > 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).
puppet/defaults sets vardir according to $0, and does this before I can modify Puppet.settings; I can obviously modify $0 instead, before require 'puppet'. > > 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 It will probably look like this: require 'lib/application/puppetmasterd' ARGV << "--rack" run Application[:puppetmasterd].run That's because config.ru will usually be eval()'d inside a Rack::Builder.new {} block. As far as I see, I can't access this "run" method from inside another context (like the Application(:puppetmasterd) context). (See http://rack.rubyforge.org/doc/classes/Rack/Builder.html for details on this.) > > * Using rack with WEBrick: > > 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. And it's definitively easier without moving everything on top of rack, as well as supporting puppetmasterd-on-rack-on-WEBrick when we don't need it. Christian -- christian hofstaedtler --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
