On Tue, 2009-06-30 at 17:29 -0400, Joe McDonagh wrote: > Brice Figureau wrote: > > On 30/06/09 23:04, Luke Kanies wrote: > > > >> On Jun 30, 2009, at 3:48 PM, Brice Figureau wrote: > >> > >> > >>> Hi, > >>> > >>> I happen to read open tickets from time to time, and I found that many > >>> time people getting a puppet error post the error message without a > >>> stack trace. > >>> Usually James or Luke answer by asking a stack trace informing the > >>> user > >>> about the --trace option. So the user usually runs puppetd with -- > >>> trace. > >>> Unfortunately about 50% of the time the error is on the server side, > >>> so > >>> a --trace on puppetd only show a trace to the REST system :-( > >>> So we add another round trip: this is frstrating for the user because > >>> she find the system more complex, and this is frustrating for us > >>> because > >>> we have to wait a long time before to even start working on a fix, > >>> which > >>> in turn is more frustrating for the users... > >>> > >>> I was wondering lately if we couldn't: > >>> > >>> 1) Inconditionally run puppetmasterd with --trace (this is completely > >>> harmless, has no performance penalty) > >>> > >> I don't really like this, partially because most people only care > >> about traces when filing tickets and also because I've tended to be a > >> bit lazy about tracing and I expect there are more traces than people > >> really want to see. I could be convinced, but that's my initial > >> thought. > >> > > > > In fact, I'm pretty sure nobody reads it's master log even when they get > > a puppet error. Only people who care (or have read the message proposed > > below in 2)) would notice it :-) > > > > But you have a good point, if there are too much false positive we'll be > > overwhelmed. > > > > > >>> 2) add a message on the client when we get an exception from the > >>> network that the error is server side and the user should have a > >>> look in > >>> their master log. > >>> > >> That is a good idea. > >> > > > > OK, I'll post a patch soon. I'm going to open a feature. > > > Why not just have a canned response that asks people to please attach > the output of a trace if they haven't done so?
This is something different. My point was that 50% or more errors are seen from the client side by the user, but originates from the server. While looking at the error it is not obvious to tell if the error is master side or client side. It's easy to print a sentence saying that the error comes from the server side, and that to troubleshoot the issue looking at the server log would help (combined to an automatic trace on the server, and you're almost ready to file a valuable ticket). Most of the time user forget the importance of the master in the Puppet equation. Note that this can be (and should be) combined with your proposal. But I'm afraid that not all users encountering a Puppet error/crash will report it. -- 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 -~----------~----~----~----~------~----~------~--~---
