Hello
I'm interest by helping fixing this but I'm not sure I will have time to dig
into Puppet code.
Moreover, it seems puppet arguments are a bit tricky because lot of arguments
are not handled in the main script, but just added to Puppet[:xxx] and test at
any place in source code, their difficult to track, and mainly to modify (I do
not want to be the guy you will change all the 'if Puppet[:trace]' with 'if
current loglevel is greater or equal to trace' :p)
Regarding to short opts, they seems to work, it just seems than in 0.24.8, in
puppetd, -D flag is never tested.
What do you think of:
1 - fix -D
2 - use Puppet::Utils::Log.level for all trace output
3 - Add --loglevel|-L option (possible value are
err,warn,notice,info,debug,trace,evaltrace)
4 - (difficult part) fix the :trace :evaltrace use in puppet code... :/
Other things should wait for Event code rewritting.
Aurelien
-------- Message d'origine--------
De: puppet-dev@googlegroups.com de la part de Luke Kanies
Date: jeu. 16/07/2009 03:00
À: puppet-dev@googlegroups.com
Objet : Re: RE : RE : RE : [Puppet-dev] Re: [PATCH/puppet 1/1] Feature #2400 :
add display changes and add them in YAML to the report
On Jul 15, 2009, at 7:29 AM, <aurelien.degrem...@cea.fr> wrote:
>
> Presently, puppetd can output 2 kinds of informations:
> - first, a trace-like output with all the 'notice:', info and
> warning/err messages.
> This is much more like a trace, usefull for understanding unexpected
> behaviour, but not really usefull for admins when they just want to
> know what was done and the errors.
> - second, a human readible output, like --summarize. Really nice for
> admins, but usefull for automatic stuff.
>
> We have two use cases for them:
> - output for humans
> - output for scripts
>
> Whatever the output is, we must know whether the puppetd output will
> be parsed by some scripts or a human.
> So, rather than having several flags for --changes, we must have a
> global switch for the whole output.
>
> So:
> -> Decide which information interest you:
> --verbose/--trace/--debug/--summarize/--changes, etc...
> -> Decide in which format you want them
> default: human readable, --output[=yaml,jason,...]
>
>
> Example:
>
> Admin use:
> # puppetd -o --no-daemonize --changes
>
> Automatic use:
> # puppetd -o --no-daemonize --changes --output=yaml | ./my-script --
> e-mail=...
>
>
> By the way:
> --no-daemonize is really boring to enter, please add a short option :)
-D theoretically works, but I just tried and it didn't actually work. :/
>
> --changes should also a short-cut also :)
Settings theoretically support a 'short' option but it appears to be
broken, so we could specify that -C would be the short option here, if
we fix the short options.
>
> Moreover:
> To control trace verbosity, admin should play with 5 flags to decide
> what they want display:
> --logdest console (only way I found to just display err/warn/notice)
> --verbose (display err/warn/notice/info)
> --trace (...)
> --debug (...)
> --evaltrace (...)
> Maybe they should be groupped around something more classical like:
> --level={err,warn,notice,info,debug,...}
> with err=0 and debug=5
> With logdest doing just what its name tell, putting log somewhere
> with no side effect.
>
>
> So, this was some of my though about admin CLI use of puppetd.
> - Control trace verbosity
> - Display sumup of what happened
> - Choose in which format you want them displayed.
I agree with all of your points.
Any interest in helping us to fix these?
>
> Aurelien
>
> -------- Message d'origine--------
> De: puppet-dev@googlegroups.com de la part de Luke Kanies
> Date: mer. 15/07/2009 00:36
> À: puppet-dev@googlegroups.com
> Objet : Re: RE : RE : [Puppet-dev] Re: [PATCH/puppet 1/1] Feature
> #2400 : add display changes and add them in YAML to the report
>
>
> On Jul 14, 2009, at 3:05 PM, Nigel Kersten wrote:
>
>>
>> On Tue, Jul 14, 2009 at 3:02 PM, James Turnbull<ja...@lovedthanlost.net
>>> wrote:
>>> Luke Kanies wrote:
>>>> Yeah, that's a good point. We've been talking about ways to make
>>>> make
>>>> the basic interaction a bit better, but you're right that
>>>> providing a
>>>> non-dump format is a good idea. How do you think we should handle
>>>> switching between the machine-readable and human-readable formats?
>>>>
>>>
>>> Can't we do both? Have a --changes flag that does both and a
>>> --changes-serial and --changes-text that outputs each variation?
>>> Add a
>>> --serialisation-format option etc.
>>
>> ++
>>
>> It's going to be a structured format internally anyway.
>>
>> I can see wanting both invocations regularly. One for end users, one
>> for automated data scraping and reporting.
>
>
> Right, the question is, what's a good interface? I don't particularly
> like supporting three settings for this one thing...
>
> --
> Real freedom lies in wildness, not in civilization.
> -- Charles Lindbergh
> ---------------------------------------------------------------------
> Luke Kanies | http://reductivelabs.com | http://madstop.com
>
>
>
>
>
> >
> <winmail.dat>
--
Beware of all enterprises that require new clothes.
-- Henry David Thoreau
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
