> More information along these lines, highlighting ease of use and > tools for users to see their catalogs, will go along way towards soothing us > touchy sysadmins.
Totally understand, I was a very touchy admin myself before working at Puppet Labs and when the tools let you down it can be frustrating. Like chair-throwing frustrating sometimes :-). This is why I switched to be a full time dev for PL, I wanted to make the experience better in my own small way. > The performance gains while nice don't have the appeal of > better troubleshooting. I'm happy to learn yet another stack, but I'd like > to be sure I'm getting some thing more than the status quo. Absolutely, and this is where I think we wouldn't have it any other way. I can think of at least a few things I hope to gain now the Puppet platform is changing, one of them at least being that I'd like to start considering fallback caches and queues on the master for PuppetDB delivery (ie. a change to the puppedb-terminus application - this was a little harder and less clean in a Ruby/Passenger world), so that when a remote PDB instance is down the message is not lost, but queued up for delivery later. Not to mention the opening up of monitoring facilities via JMX and such, which should expose a fair amount of metrics just on its own, but allows us to poke holes into our application expose to users what things are doing for monitoring/alerting purposes. In PDB we have a great HTTP/JMX bridge for those who don't want to use JMX itself also (a consideration for admins btw - as pure JMX isn't always desirable), hopefully we'll port that over to our other services in time (we'll make it a trapperkeeper plugin most probably - so all our applications get it) but for now JMX is there and able to be used right now. We hope to hear more about where people want to go with this tooling as well, so please let us know where we are going wrong. Its very easy to create an insular application that doesn't expose enough, but another thing to create a great tooled eco-system. > The information around tuning Passenger/Puppet explicitly provided > by Puppet Labs was mostly crap. Indeed, it was a bit of a black art because of this. It wasn't until later that Passenger even added the ability to reasonably introspect what was going on in Passenger. > It would be extremely useful for everyone if > there were 4-8 pages of serious and indepth docs specifically about running > puppet_server on the JVM. If that doesn't happen, you'll be fighting the > supposed poor performance of every un-tuned puppet_server installation for > years. Sounds like something ticket-worthy to mention. We already have some of this for PuppetDB, a lot of it is similar for this platform as well. I'm pretty sure this will become a hot topic, so I doubt it will be left alone. I expect the new puppet-server to incur more traffic than PuppetDB for example, so they'll probably see issues we have not. Not only that, as you see issues you should be bringing them up in these forums - and then we can discuss and feed that back into the docs as we go (as you know most of our docs are user-contributable as well, to make it easier). We can do as much benchmarking as we like in the lab, but the real world is the only true learning ground. I've been following Puppet for gosh, 7-8 years or something now, in the forums and such - and one thing I've always enjoyed is how well we taught each other. At the very least I can tell you the web server is Jetty, and will have tuning similar to PuppetDB. It has all the predominant tuning items one would expect, like # of threads, but hopefully the reduction in moving parts should actually help. Not only that, I've recently patched the trapperkeeper plugin for Jetty so it exposes its JMX monitoring capabilities: https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/commit/cb727a4731bc7e2df7151c93a1b9f91461823a91 Which I really wanted for PuppetDB, but the beauty of trapperkeeper is that we all get it now. This means you get all kinds of introspection into what the web server is doing, much like you would with Apache, but in a potentially more curated/monitoring prepared way (I'm not trying to upset an Apache fans here, I love Apache as well, but we couldn't easily embed it :-). ken. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAE4bNTnKUSwOp1jRb4-67Rd%2Bcc2%2Bc8NxBtKoVKzfYGjqsmMCTw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
