cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
From: Fabio M. Di Nitto <fdinitto@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] fenced logsys/cman/ccs setup
Date: Wed, 2 Jul 2008 06:31:10 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0807020609520.27368@trider-g7> (raw)
In-Reply-To: <20080701212844.GF1259@redhat.com>


Hi David,

I didn't test the patch directly, but I have a few comments.

> index 56b7b0e..f2a8372 100644
> --- a/fence/fenced/config.c
> +++ b/fence/fenced/config.c
> @@ -1,7 +1,9 @@
> #include "fd.h"
> #include "ccs.h"
>
> -static int open_ccs(void)
> +static int ccs_handle;
> +
> +int setup_ccs(void)
> {
> 	int i = 0, cd;
>
> @@ -9,18 +11,62 @@ static int open_ccs(void)
> 		sleep(1);
> 		if (++i > 9 && !(i % 10))
> 			log_error("connect to ccs error %d, "
> -				  "check ccsd or cluster status", cd);
> +				  "check cluster status", cd);
> +
> +		/* FIXME: do we want this infinite? */
> +		if (i > 10)
> +			break;

I think we want this to be infinite (and consistent across the board) or 
configurable the same way other daemons/tools do so that users can decide 
how long to wait.

> @@ -122,7 +165,6 @@ int read_ccs(struct fd *fd)
>
> 	log_debug("added %d nodes from ccs", count);
>  out:
> -	ccs_disconnect(cd);
> 	return 0;
> }

I don't see any call to ccs_disconnect around. We still need to invoke it 
on exit to close the connection to the objdb when we exit and release 
aisexec resources.

> +#define DEFAULT_FACILITY	LOG_DAEMON

You can either do:

#define DEFAULT_FACILITY SYSLOGFACILITY

or just use SYSLOGFACILITY instead.

SYSLOGFACILITY is defined by the build system as default build option and 
can be set by packagers according to distro rules/best practice/etc.

> +#define DEFAULT_PRIORITY	LOG_LEVEL_ERROR

I don't have a DEFAULT_PRIORITY in the build system (maybe i can add it) 
but it should be LOG_LEVEL_INFO. At least this is the best practise we 
used so far.

> +#define DEFAULT_FILE		NULL

#define DEFAULT_FILE LOGDIR "/fenced.log"

LOGDIR is set by the build system (same reasons as SYSLOGFACILITY). We 
want files by default consistently across the board.

> +#define LEVEL_PATH "/cluster/logging/logger_subsys[@subsys=\"FENCED\"]/@syslog_level"
> +#define DEBUG_PATH "/cluster/logging/logger_subsys[@subsys=\"FENCED\"]/@debug"

I am kind of curious.. why do you add defines for some queries but not for 
others?

> +
> +/* 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.
> +
> +   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 logic is almost ok.

You need to check for:

/cluster/logging/@debug - global debug on/off switch.

the other daemons respects globla debug setting if no subsystem debug 
setting is available.

You also want to allow debugging to be set via cmdline and envvar.

This allows a great control of debugging.

The use cases are:

- set /cluster/logging/@debug to on:
   all daemons across the whole cluster are in debug mode (and logging
   debug info). You don't need to add X subsystem lines to achieve this.

- /cluster/logging/logger_subsys[@subsys=\"prog_name\"]/@debug:
   users either want to debug only this system or disable debugging only
   for this subsystem across the whole cluster when master debug is on.

- cmdline debug:
   allows the user to enable debugging manually only on that specific
   daemon on that specific node.

- envvar debug on (see for example CMAN_DEBUG or CCSD_DEBUG or QDISK_...):
   these are easy to set within init scripts and /etc/defaults/... without
   changing the daemon invokation in the init script itself that is not
   always trivial and it is not a recommended practise.
   the use case is similar (but more flexible) to the cmdline debug.
   It allows the users to enable debugging for one specific node.

cmdline and envvar debugging overrides whatever is in the config.

Fabio

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



  reply	other threads:[~2008-07-02  4:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-01 21:28 [Cluster-devel] fenced logsys/cman/ccs setup David Teigland
2008-07-02  4:31 ` Fabio M. Di Nitto [this message]
2008-07-02 15:49   ` David Teigland
2008-07-02 18:00     ` David Teigland
2008-07-02 18:22       ` Fabio M. Di Nitto
2008-07-02 18:59         ` David Teigland
2008-07-02 19:18           ` Fabio M. Di Nitto
2008-07-02 18:21     ` Fabio M. Di Nitto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0807020609520.27368@trider-g7 \
    --to=fdinitto@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).