Thanks Chris, this is both helpful and reassuring. DOCUMENT-389 for fake Internet points.
Trevor On Thu, Jul 16, 2015 at 6:46 AM, Chris Price <[email protected]> wrote: > On Thu, Jul 16, 2015 at 8:56 AM, Nan Liu <[email protected]> wrote: > >> On Wednesday, July 15, 2015 at 7:06:42 PM UTC-7, Trevor Vaughan wrote: >>> >>> So, we ran across this one today and I dug up the thread where Felix >>> Frank, John Bolinger, and I all agreed (https://goo.gl/LQ20bj) that >>> there were solid use cases for keeping the Webrick version of Puppet around. >>> >>> We were all fine with losing Rack support but, as of right now, I do not >>> know how to debug the internals of the server-side Ruby code within the >>> Clojure stack. >>> >>> As far as I can tell, I can't do the following in Puppet Server: >>> >>> 1) Stuff Pry into the middle of the stack and interact with it so that >>> you can inspect the internal state of the Puppet Master process while >>> testing custom types, functions, and providers. >>> >> >> The documentation for using pry is here: >> https://github.com/puppetlabs/puppet-server/blob/master/documentation/dev_debugging.markdown >> >> 2) Easily debug the *server* portions of the Ruby code >>> >> >> Yeah, I wish there's a wrapper similar to puppet master --compile for the >> puppet-server stack. The example I got from support doesn't work and I >> haven't chased down the issue yet, maybe it works for other people: >> >> /opt/puppet/bin/java -cp >> /opt/puppet/share/puppetserver/puppet-server-release.jar org.jruby.Main >> -I/opt/puppet/lib/ruby/site_ruby/1.9.1 /opt/puppet/bin/puppet master >> --compile <certname> --trace >> WARNING: unimplemented method called: request#signature_algorithm >> Error: Could not prepare for execution: Unknown signature algorithm '' >> > > FWIW there is now a 'puppetserver ruby' command, that should effectively > be the equivalent of running 'ruby' from the CLI, but it'll run things > using the built-in Puppet Server JRuby. So you should be able to do > 'puppetserver ruby /opt/puppet/bin/blah'. > >> >> 3) Spin up a lightweight Puppet server instance for trying/debugging some >>> code on a laptop of limited resources >>> >>> Looking over PUP-4435, I don't see any indication as to exactly *why* we >>> can't keep Webrick support or how to do the three items above. >>> >>> Digging into the referred ticket of PUP-4394, it seems like it would be >>> relatively easy to either gracefully bail if the puppet user/group don't >>> exist or, alternatively, to create them as an option. >>> >>> Yes, throw all sorts of "don't use this in production" warnings, but I >>> need to know how to do the three things above prior to losing Webrick >>> support because the code in 'puppet apply' doesn't work the same way as the >>> puppet server compiler in all cases. >>> >> >> puppet-server doesn't always behave the same as the ruby server code, so >> I don't know if it's actually helpful. A few issues I run into are around >> https connection (due to jruby) and environment variable preservation >> (SERVER-584) that only occur with the puppet-server stack. I would agree a >> few debugging examples in the documentation target at ruby v.s. closure >> code would be really helpful since we are poking at code three layers deep. >> > > I am definitely willing to write up some more docs (and also advocate w/in > PL to get some dev time to spend on filing a few PRs to pry-related > projects to improve their JRuby compatibility). Would any of you be > willing to create a Jira ticket that describes what sort of example would > be the most useful to you? I will make sure it gets prioritized, at the > *very* least before webrick support is removed. > > To Trevor's question of why webrick support will be removed: it's mostly > that we intend to move a lot more of the network/HTTP parts of the logic > into pure Clojure and it's very expensive and complicated for us to > maintain both Ruby and Clojure versions of the code; so there will > necessarily be code deleted from the Puppet ruby codebase that would be > required in order to run under webrick. > > As to the question about running Puppet Server on a laptop--we do this in > dev all the time, so if you're running into any hardware / resource issues > that are causing you trouble, I would love to hear more details so that we > can look into it. > > That said, I definitely don't take these concerns lightly and will work > really hard to make sure that we've addressed them as completely as > possible prior to the switch-over. Please keep bringing the concerns to > our attention, and bonus points for filing Jira tickets around individual > items that you want to make sure we cover. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/CAMx1QfJTAdnhaN8TtJveY-9pH7skmH-j8qHdVnSp%3Djod_JXFzw%40mail.gmail.com > <https://groups.google.com/d/msgid/puppet-dev/CAMx1QfJTAdnhaN8TtJveY-9pH7skmH-j8qHdVnSp%3Djod_JXFzw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUbKsdCeOAgGErvqScM4mfaY6hpa6FqA7OpVWWu1R4mdA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
