[Cluster-devel] clulog

[Cluster-devel] clulog

[Lon Hohberger]

[10:56:21] <fabbione> lon: you around?
----- [11:00] -----
[11:01:39] <fabbione> ok no biggies.. i need to run to a meeting now
[11:02:17] <fabbione> idea: make clulog a shared standalone library,
remove a bunch of custom log.h/.c like the one in ccs
                      and make them use clulog lib
[11:02:33] <fabbione> i have notice that most of them do the exact same
thing with different name
[11:02:37] <fabbione> == code reduction
[11:02:50] <fabbione> more clean and elegant than reimplement * each
time
[11:03:03] <fabbione> just think about it.. we can talk next time we are
both online
[11:03:08] * fabbione takes off


Really - what we need is a better logging system.  clulog is just a
wrapper around syslog.  Some of the features we really need are:

 * ring-buffer style (w/ a fixed max size)
   * Remove oldest / lowest-prio log messages if we run out of
     room
 * option of guaranteed non-blocking logging

clulog could be expanded and library-ified - esp. now that we have a
better / single build system.

What I'd do is:

  * clulog_init(const char *facility, int mode, int severity)
	  MODE_SIMPLE   - what we have now.
      MODE_NONBLOCK - simple nonblocking syslog() calls.  e.g. do what
		syslog() does, but open the log device O_NONBLOCK; lossy.
      MODE_RINGBUF  - Non-blocking; fixed maximum memory footprint.
        Clears lowest-prio / oldest log messages first if we fill up.

etc... etc...  I'll do more on this later. 

-- Lon

-- 
Lon Hohberger - Software Engineer - Red Hat, Inc.

[Cluster-devel] Re: clulog

[Fabio M. Di Nitto]

Lon Hohberger wrote:

> 
> Really - what we need is a better logging system.  clulog is just a
> wrapper around syslog.

Yes exactly as some other log.c/.h that are around the tree.

>  Some of the features we really need are:
> 
>  * ring-buffer style (w/ a fixed max size)
>    * Remove oldest / lowest-prio log messages if we run out of
>      room
>  * option of guaranteed non-blocking logging
> 
> clulog could be expanded and library-ified - esp. now that we have a
> better / single build system.
> 
> What I'd do is:
> 
>   * clulog_init(const char *facility, int mode, int severity)
> 	  MODE_SIMPLE   - what we have now.
>       MODE_NONBLOCK - simple nonblocking syslog() calls.  e.g. do what
> 		syslog() does, but open the log device O_NONBLOCK; lossy.
>       MODE_RINGBUF  - Non-blocking; fixed maximum memory footprint.
>         Clears lowest-prio / oldest log messages first if we fill up.
> 
> etc... etc...  I'll do more on this later. 

How would you feel if we first extract the code in its own library,
switch all the subproject to it and then implement features?

I think that in this way we will have to look at much less code than we
have now.

Thanks
Fabio

-- 
I'm going to make him an offer he can't refuse.

[Cluster-devel] Re: clulog

[Steven Dake]

On Tue, 2007-05-08 at 08:52 +0200, Fabio M. Di Nitto wrote:
> Lon Hohberger wrote:
> 
> > 
> > Really - what we need is a better logging system.  clulog is just a
> > wrapper around syslog.
> 
> Yes exactly as some other log.c/.h that are around the tree.
> 
> >  Some of the features we really need are:
> > 
> >  * ring-buffer style (w/ a fixed max size)
> >    * Remove oldest / lowest-prio log messages if we run out of
> >      room
> >  * option of guaranteed non-blocking logging
> > 
> > clulog could be expanded and library-ified - esp. now that we have a
> > better / single build system.
> > 
> > What I'd do is:
> > 
> >   * clulog_init(const char *facility, int mode, int severity)
> > 	  MODE_SIMPLE   - what we have now.
> >       MODE_NONBLOCK - simple nonblocking syslog() calls.  e.g. do what
> > 		syslog() does, but open the log device O_NONBLOCK; lossy.
> >       MODE_RINGBUF  - Non-blocking; fixed maximum memory footprint.
> >         Clears lowest-prio / oldest log messages first if we fill up.
> > 
> > etc... etc...  I'll do more on this later. 
> 
> How would you feel if we first extract the code in its own library,
> switch all the subproject to it and then implement features?
> 
> I think that in this way we will have to look at much less code than we
> have now.
> 
> Thanks
> Fabio
> 

Probably a bit late to this conversation, but I'd suggest taking a look
at openais logging (print.c, print.h, and wthread.{c|h}) since its
already a dependency of RHCS.  We can library-ify (its pretty much
already a library) the logging system which is non blocking and drops
messages on overload and records that messages were dropped.

Regards
-steve

[Cluster-devel] Re: clulog

[Fabio Massimo Di Nitto]

Steven Dake wrote:

> 
> Probably a bit late to this conversation,

not at all.

> but I'd suggest taking a look
> at openais logging (print.c, print.h, and wthread.{c|h}) since its
> already a dependency of RHCS. 

Lon was already looking at it and we had a conversation on IRC today.

> We can library-ify (its pretty much
> already a library) the logging system which is non blocking and drops
> messages on overload and records that messages were dropped.

Lon raised a few points that I think he planned to ask you directly but it's 
doable IMHO.

My only personal concern (and i don't hide it) is that the cluster suite 
needs/would like to have some extra logging functionality and that the patch 
inclusion policy for openais might slow that down a bit but clearly if there is 
cooperation I don't see it as blocker.

Regards
Fabio

-- 
I'm going to make him an offer he can't refuse.

[Cluster-devel] Re: clulog

[Lon Hohberger]

On Tue, May 15, 2007 at 08:24:30PM +0200, Fabio Massimo Di Nitto wrote:
> Steven Dake wrote:
> 
> >
> >Probably a bit late to this conversation,
> 
> not at all.
> 
> >but I'd suggest taking a look
> >at openais logging (print.c, print.h, and wthread.{c|h}) since its
> >already a dependency of RHCS. 
> 
> Lon was already looking at it and we had a conversation on IRC today.
> 
> >We can library-ify (its pretty much
> >already a library) the logging system which is non blocking and drops
> >messages on overload and records that messages were dropped.
> 
> Lon raised a few points that I think he planned to ask you directly but 
> it's doable IMHO.

Talked with Steve on IRC a bunch; he's going to build a first pass
pretty soon

-- Lon

-- 
Lon Hohberger - Software Engineer - Red Hat, Inc.