[Cluster-devel] logsys in cluster3

[Cluster-devel] logsys in cluster3

[David Teigland]

Main points from the logsys discussion we had

- initialization: use functions instead of macros, don't always need
  logging to be working from the start of execution, can wait until
  function is called to start it, don't need notion of "subsystems"
  or per-source-file logging features

- configuration setup: big blocks of setup code are repeated and largely
  the same, make this less

- configuration changes: user should be able to change logging settings
  in cluster.conf, propagate new cluster.conf, ccs should notify programs
  of cluster.conf change, programs should reread whatever dynamic config
  settings they use (may just be the logging settings), programs should
  then change behavior according to the new settings

[Cluster-devel] logsys in cluster3

[Fabio M. Di Nitto]

On Mon, 30 Jun 2008, David Teigland wrote:

> - configuration setup: big blocks of setup code are repeated and largely
>  the same, make this less

I will take care of this bit since i already done it.

the api will look like:

int gimme_logging_config_data(char *name, int debug)

return 0 if ok 1 on failure
char *name is the subsystem name as declared
debug = 0 if no debug override is coming from cli or envvar, 1 if debug 
has been forced by cli or envvar.

I still would like to agree on be able to try to config logging as early 
as possible and then try later if it fails tho.

This problem would just disappear if we can agree on the other common 
cluster connection bit. At that point, we configure once we connect and we 
keep logging only the attempts to connect. Everybody is happy everafter ;)

>  ccs should notify programs
>  of cluster.conf change,

cman will take care of this since ccs is just a plugin now and cman has 
the API there and i see little gain to do it again. Ok?

Fabio

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

[Cluster-devel] logsys in cluster3

[David Teigland]

On Mon, Jun 30, 2008 at 06:38:48PM +0200, Fabio M. Di Nitto wrote:
> On Mon, 30 Jun 2008, David Teigland wrote:
> 
> >- configuration setup: big blocks of setup code are repeated and largely
> > the same, make this less
> 
> I will take care of this bit since i already done it.
> 
> the api will look like:
> 
> int gimme_logging_config_data(char *name, int debug)
> 
> return 0 if ok 1 on failure
> char *name is the subsystem name as declared
> debug = 0 if no debug override is coming from cli or envvar, 1 if debug 
> has been forced by cli or envvar.
> 
> I still would like to agree on be able to try to config logging as early 
> as possible and then try later if it fails tho.
> 
> This problem would just disappear if we can agree on the other common 
> cluster connection bit. At that point, we configure once we connect and we 
> keep logging only the attempts to connect. Everybody is happy everafter ;)
> 
> > ccs should notify programs
> > of cluster.conf change,
> 
> cman will take care of this since ccs is just a plugin now and cman has 
> the API there and i see little gain to do it again. Ok?

OK, the details are still a little hazy for starting up a program.  When a
program starts up it needs to interact with cman, ccs and logsys, and all
three of those are somewhat interdependent.

- setup logsys nominally, so that the cman/ccs setup steps can do logging
  . if this fails, just go on

- connect to cman
  . if this fails, exit (hopefully the nominal logging above worked)

- wait for cman to be fully running
  . do we want everyone to put a finite loop around this?
  . if this fails, exit
  . keep the cman connection open as long as the program is running

- connect to ccs
  . could this fail even if cman is already ok above?  do we need a
    retry loop here?
  . keep the ccs connection open as long as the program is running

- read from ccs the optional cluster.conf logging settings
  . if this fails, just go on
  . reconfigure logsys, replacing the nominal config in step 1

- as the program runs, ccs/cman notifications may arrive indicating
  that cluster.conf has changed. when one of these callbacks arrives:
  . reread the logsys config and modify logging behavior accordingly
  . reread any other dynamic cluster.conf settings
  . (I assume I poll on the ccs connection fd which tells me when there's
     a change?)

Is there anything missing?

[Cluster-devel] logsys in cluster3

[Fabio M. Di Nitto]

On Mon, 30 Jun 2008, David Teigland wrote:

> On Mon, Jun 30, 2008 at 06:38:48PM +0200, Fabio M. Di Nitto wrote:
>> On Mon, 30 Jun 2008, David Teigland wrote:
>>
>>> - configuration setup: big blocks of setup code are repeated and largely
>>> the same, make this less
>>
>> I will take care of this bit since i already done it.
>>
>> the api will look like:
>>
>> int gimme_logging_config_data(char *name, int debug)
>>
>> return 0 if ok 1 on failure
>> char *name is the subsystem name as declared
>> debug = 0 if no debug override is coming from cli or envvar, 1 if debug
>> has been forced by cli or envvar.
>>
>> I still would like to agree on be able to try to config logging as early
>> as possible and then try later if it fails tho.
>>
>> This problem would just disappear if we can agree on the other common
>> cluster connection bit. At that point, we configure once we connect and we
>> keep logging only the attempts to connect. Everybody is happy everafter ;)
>>
>>> ccs should notify programs
>>> of cluster.conf change,
>>
>> cman will take care of this since ccs is just a plugin now and cman has
>> the API there and i see little gain to do it again. Ok?
>
> OK, the details are still a little hazy for starting up a program.  When a
> program starts up it needs to interact with cman, ccs and logsys, and all
> three of those are somewhat interdependent.
>

This is almost right.

> - setup logsys nominally, so that the cman/ccs setup steps can do logging
>  . if this fails, just go on
>
> - connect to cman
>  . if this fails, exit (hopefully the nominal logging above worked)

We want to loop here too. Maybe the init script has fired cman, and the 
next daemon but cman might not have setup sockets yet.

> - wait for cman to be fully running
>  . do we want everyone to put a finite loop around this?
>  . if this fails, exit
>  . keep the cman connection open as long as the program is running

Right.

> - connect to ccs
>  . could this fail even if cman is already ok above?  do we need a
>    retry loop here?

Yes it can fail if there are no resources available, if we already have 
the cman connection, we don't need to loop and we die on error.

>  . keep the ccs connection open as long as the program is running

Right.

> - read from ccs the optional cluster.conf logging settings
>  . if this fails, just go on
>  . reconfigure logsys, replacing the nominal config in step 1

Right.

> - as the program runs, ccs/cman notifications may arrive indicating
>  that cluster.conf has changed. when one of these callbacks arrives:
>  . reread the logsys config and modify logging behavior accordingly
>  . reread any other dynamic cluster.conf settings

Right.

>  . (I assume I poll on the ccs connection fd which tells me when there's
>     a change?)

No. You can just install the callback and be done with it. The ccs fd was 
never a real fd to poll.

> Is there anything missing?

Given that this code is going to be re-implemented N times, I suggest 
again to create a cluster/common/helpers with pre-built objects to just 
include at linking time (note that we also share and duplicate a lot of 
header files around and it was in my mind for sometime to create a 
cluster/common/includes too)

For now i can see that at least the connection sequence and the logsys 
config are exactly two candidates for being there.

There is also the option to make a brand new shared library called 
libcluhelpers that IMHO is a bit more clean than just linking objects.

Fabio

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

[Cluster-devel] logsys in cluster3

[David Teigland]

On Tue, Jul 01, 2008 at 07:01:42AM +0200, Fabio M. Di Nitto wrote:
> No. You can just install the callback and be done with it. The ccs fd was 
> never a real fd to poll.

OK, it's a cman callback.  If the ccs "connection" isn't really a
connection and if it's not necessary then can we get rid of the illusion?


> Given that this code is going to be re-implemented N times, I suggest 
> again to create a cluster/common/helpers with pre-built objects to just 
> include at linking time (note that we also share and duplicate a lot of 
> header files around and it was in my mind for sometime to create a 
> cluster/common/includes too)

Let's get the code in place and replicated first, before trying to factor
it.  And I don't think it needs to be too complicated.  Assuming I can
make my simplified logsys api work (really, we're trying to solve stuff in
parallel here that should be sequential)...


/* Read cluster.conf settings and convert them into logsys values.
   If no cluster.conf setting exists, the default that was used in
   logsys_init() is used. */

int read_ccs_logging(int *mode, int *facility, int *priority, char *file,
		     int *debug)
{
	*mode = MYPROG_DEFAULT_MODE;
	*facility = MYPROG_DEFAULT_FACILITY;
	*priority = MYPROG_DEFAULT_PRIORITY;
	strcpy(file, MYPROG_DEFAULT_FILE);

	/* Read settings from ccs to override the defaults above.
	   (with some appropriate helper functions around ccs_get, the
	   following can be pretty compact)

	   mode from
	   "/cluster/logging/@to_stderr"
	   "/cluster/logging/@to_syslog"
	   "/cluster/logging/@to_file"

	   facility from
	   "/cluster/logging/@syslog_facility"

	   priority from
	   "/cluster/logging/logger_subsys[@subsys=\"prog_name\"]/@syslog_level"

	   file from
	   "/cluster/logging/@filename"

	   debug from
	   "/cluster/logging/logger_subsys[@subsys=\"prog_name\"]/@debug"
	*/
}

/* this function will also be called when we get a cman config-update event */

void setup_logging(int *prog_debug)
{
	int mode, facility, priority;
	char *file;

	/* The debug setting is special, it's used by the program
	   and not used to configure logsys. */

	read_ccs_logging(&mode, &facility, &priority, file, prog_debug);
	logsys_conf(mode, facility, priority, file);
}

int main(int argc, char **argv)
{
	logsys_init(MYPROG_DEFAULT_MODE, MYPROG_DEFAULT_FACILITY,
		    MYPROG_DEFAULT_PRIORITY, MYPROG_DEFAULT_FILE);

	/* set up cman/ccs connections ... */

	setup_logging(&prog_debug);
}

[Cluster-devel] logsys in cluster3

[David Teigland]

Here's a patch that adds a simple, function-based api to logsys, allowing
non-plugins to use it much more cleanly.  It seems to mostly work with the
attached test program, which illustrates how I expect to use it in various
cluster3 programs.  (What doesn't work yet is the "test 1" output
following the logsys_init() call.)


Index: logsys.c
===================================================================
--- logsys.c	(revision 1568)
+++ logsys.c	(working copy)
@@ -632,3 +632,32 @@
 {
 	worker_thread_group_wait (&log_thread_group);
 }
+
+int logsys_init(char *name, int mode, int facility, int priority, char *file)
+{
+	char *errstr;
+	logsys_config_mode_set(mode);
+	logsys_config_facility_set(name, facility);
+	logsys_config_file_set(&errstr, file);
+	_logsys_config_priority_set(0, priority);
+	if ((mode & LOG_MODE_BUFFER_BEFORE_CONFIG) == 0) {
+		_logsys_wthread_create();
+	}
+	return 0;
+}
+
+int logsys_conf(char *name, int mode, int facility, int priority, char *file)
+{
+	char *errstr;
+	logsys_config_mode_set(mode);
+	logsys_config_facility_set(name, facility);
+	logsys_config_file_set(&errstr, file);
+	_logsys_config_priority_set(0, priority);
+	return 0;
+}
+
+int logsys_exit(void)
+{
+	return 0;
+}
+
Index: logsys.h
===================================================================
--- logsys.h	(revision 1568)
+++ logsys.h	(working copy)
@@ -170,8 +170,9 @@
 	}								\
 }
 
+static unsigned int logsys_subsys_id __attribute__((unused));		\
+
 #define LOGSYS_DECLARE_NOSUBSYS(priority)				\
-static unsigned int logsys_subsys_id __attribute__((unused));		\
 __attribute__ ((constructor)) static void logsys_nosubsys_init (void)	\
 {									\
 	_logsys_nosubsys_set();						\
@@ -180,7 +181,6 @@
 }
 
 #define LOGSYS_DECLARE_SUBSYS(subsys,priority)				\
-static unsigned int logsys_subsys_id __attribute__((unused));		\
 __attribute__ ((constructor)) static void logsys_subsys_init (void)	\
 {									\
 	logsys_subsys_id =						\
@@ -293,4 +293,10 @@
 	_logsys_config_priority_set (logsys_subsys_id, priority);       \
 } while(0)
 
+/* simple, function-based api */
+
+int logsys_init(char *name, int mode, int facility, int priority, char *file);
+int logsys_conf(char *name, int mode, int facility, int priority, char *file);
+int logsys_exit(void);
+
 #endif /* LOGSYS_H_DEFINED */
-------------- next part --------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include "logsys.h"

#define DEFAULT_MODE		LOG_MODE_OUTPUT_STDERR
#define DEFAULT_FACILITY	LOG_DAEMON
#define DEFAULT_PRIORITY	LOG_LEVEL_INFO
#define DEFAULT_FILE		NULL

char *prog_name;
int prog_debug;

/* Read cluster.conf settings and convert them into logsys values.
   If no cluster.conf setting exists, the default that was used in
   logsys_init() is used. */

int read_ccs_logging(int *mode, int *facility, int *priority, char *file,
                     int *debug)
{
	*mode = DEFAULT_MODE;
	*facility = DEFAULT_FACILITY;
	*priority = DEFAULT_PRIORITY;

	if (DEFAULT_FILE)
		strcpy(file, DEFAULT_FILE);

	/* Read settings from ccs to override the defaults above.
	   (with some appropriate helper functions around ccs_get, the
	   following can be pretty compact)

           mode from
           "/cluster/logging/@to_stderr"
           "/cluster/logging/@to_syslog"
           "/cluster/logging/@to_file"

           facility from
           "/cluster/logging/@syslog_facility"

           priority from
           "/cluster/logging/logger_subsys[@subsys=\"prog_name\"]/@syslog_level"

           file from
           "/cluster/logging/@filename"

           debug from
           "/cluster/logging/logger_subsys[@subsys=\"prog_name\"]/@debug"
        */

	*mode = LOG_MODE_OUTPUT_FILE;
	*priority = LOG_LEVEL_DEBUG;
	strcpy(file, "/tmp/testprog.log");

	return 0;
}

/* this function will also be called when we get a cman config-update event */

void setup_logging(int *prog_debug)
{
	int mode, facility, priority;
	char file[1024];

	/* The debug setting is special, it's used by the program
	   and not used to configure logsys. */

	read_ccs_logging(&mode, &facility, &priority, file, prog_debug);
	logsys_conf(prog_name, mode, facility, priority, file);
}

int main(int argc, char **argv)
{
	prog_name = argv[0];

	logsys_init(prog_name, DEFAULT_MODE, DEFAULT_FACILITY,
		    DEFAULT_PRIORITY, DEFAULT_FILE);

	log_printf(LOG_LEVEL_ERROR, "error test 1\n");
	log_printf(LOG_LEVEL_DEBUG, "debug test 1\n");

	setup_logging(&prog_debug);

	log_printf(LOG_LEVEL_ERROR, "error test 2\n");
	log_printf(LOG_LEVEL_DEBUG, "debug test 2\n");
}

[Cluster-devel] logsys in cluster3

[David Teigland]

On Tue, Jul 01, 2008 at 12:21:21PM -0500, David Teigland wrote:
> (What doesn't work yet is the "test 1" output
> following the logsys_init() call.)

was missing logsys_flush()


> +int logsys_init(char *name, int mode, int facility, int priority, char *file)
> +{
> +	char *errstr;

Thinking about prefixing, when the mode is set to use syslog, syslog willl
add a prefix for us, otherwise we might want a prefix like this?

        strncpy(logsys_loggers[0].subsys, name,
                sizeof(logsys_loggers[0].subsys));

> +	logsys_config_mode_set(mode);
> +	logsys_config_facility_set(name, facility);
> +	logsys_config_file_set(&errstr, file);
> +	_logsys_config_priority_set(0, priority);
> +	if ((mode & LOG_MODE_BUFFER_BEFORE_CONFIG) == 0) {
> +		_logsys_wthread_create();
> +	}
> +	return 0;