Just for the record, Steven and I had a chat on IRC. This is the
transcript:
07:51 < riley_dt> yes i read your original message
07:52 < riley_dt> i was reswponding to your email not dave's
07:52 < riley_dt> your right i had not read dave's message at all
07:53 < fabbione> riley_dt: well.. nothing I can do about that, but the
thread is evolving in a positive direction
IMHO. There are only few bits that needs smoothing
07:53 < riley_dt> i see the correction in dave's email
07:53 < fabbione> and I am simply talking from the end of the thread. I
can't possible know what have you read or not
07:54 < riley_dt> well you can put debug in the top level config
07:54 < riley_dt> but i dont intend to do anything about it :)
07:55 < fabbione> riley_dt: and that _IS_ fine :)
07:55 < fabbione> riley_dt: allow others to use it if they want
07:55 < riley_dt> also the oring has to go
07:55 < fabbione> oring?
07:55 < riley_dt> DEBUG|WARN
07:55 < riley_dt> should be DEBUG then debug+ are logged
07:55 < fabbione> there is no oring...
07:55 < fabbione> it's an example to show what values can be there
07:55 < fabbione> you can't ORING priorities
07:56 < riley_dt> you could or select priorities
07:56 < riley_dt> i thought that is what you proposed
07:56 < riley_dt> then we are good to go
07:56 < fabbione> no.. simply a list of options
07:56 < fabbione> i received some comments from other people in my inbox
that I need to sort out
07:56 < fabbione> they didn't go to mailing lists
07:56 < riley_dt> well for trace there is oring
07:56 < riley_dt> ie: TRACE1|TRACE2
07:57 < riley_dt> it isn't "trace 1 or trace2" it is an oring
07:57 < fabbione> some are really good points.. so before everybody
dives into implementing, let's wait for the "final
email"
07:57 < fabbione> gotcha...
07:57 < riley_dt> when I see | I think "or"
07:57 < riley_dt> overloaded term i guess
08:49 < fabbione> riley_dt: just for the record, can you please reply to
thread and tell that you understood what we
have been talking about? I strongly want to avoid the
situation where in 2 months from now we will be
fighting again:" I said this, not this, understood
that etc."
10:11 < riley_dt> sure
On Mon, 2008-11-10 at 23:00 -0700, Steven Dake wrote:
> On Tue, 2008-11-11 at 06:54 +0100, Fabio M. Di Nitto wrote:
> > On Mon, 2008-11-10 at 22:47 -0700, Steven Dake wrote:
> > > On Tue, 2008-11-11 at 05:55 +0100, Fabio M. Di Nitto wrote:
> > > > On Mon, 2008-11-10 at 17:46 -0700, Steven Dake wrote:
> > > > > I disagree with a global debug keyword.
> > > > > At one time I thought it was a
> > > > > good idea but that time has long since passed. The idea of turning
> > > > > debug to on and then having all debug output go to syslog is frightening
> > > > > and will result in lost messages. While it appears this proposal
> > > > > includes the selectable log output filtering per output medium as was
> > > > > discussed already, it is unclear how the debug keyword affects this. It
> > > > > would simply make sense to change the file's log priority or the
> > > > > syslog's log priority if that is the behavior desired and then no need
> > > > > for any extra keyword.
> > > >
> > > > You have these two situations:
> > > >
> > > > print_log(LOG_DEBUG, "doing this and that....\n");
> > > >
> > > > if (debug) { /*
> > > > gather_some_data_that_is_very_expensive_operation_to_do_all_the_time();
> > > > print_log(LOG_DEBUG, "print those extra data\n");
> > > > }
> > > >
> > > > as it is now, it would basically be an alias to set logpriority to DEBUG
> > > > but enables people to execute debugging code conditionally and as I
> > > > wrote it is an easy keyword to remember compared to
> > > > syslog_priority/logpriority.
> > > >
> > > > Fabio
> > > >
> > >
> > > The second situation doesn't exist in any code I have written and never
> > > would.
> >
> > Clearly you haven't read what I wrote in the debugging note.
> >
>
> I read it but don't agree you can have a discussion about logging and
> flight recording without discussing how debugging fits into the log
> system.
>
>
> > > Turning debug on for all of the entire stack to be output to syslog is
> > > not satisfactory because messages would be lost in overload conditions.
> > > Logging to file is only a slight bit better solution but if you really
> > > must have debug output in a persistent store that doesn't occur as a
> > > result of a failure, logging to file is the only suitable answer.
> >
> > Please point me to where I wrote that it should go to syslog as I only
> > mentioned logfile_priority so far.
> >
>
> If syslog is configured it will go to syslog by default in your scheme.
>
> Regards
> -steve
>
> > Fabio
> >
>
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
