From: Lon Hohberger <lhh@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [RFC] Configuring logging system for master
Date: Tue, 10 Jun 2008 09:19:03 -0400 [thread overview]
Message-ID: <1213103943.20204.16.camel@ayanami.boston.devel.redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0806021102280.5892@trider-g7>
On Mon, 2008-06-02 at 12:05 +0200, Fabio M. Di Nitto wrote:
> Hi guys,
>
> there has been a halt on porting daemons to the new logsys library because
> there is a small disagreement on how the configuration bits should be
> reflected in cluster.conf (or equivalent).
>
> It's about time to take a decision to complete this transition.
>
> The 2 current methods are:
>
> 1) as implemented by cman:
>
> <cluster>
> <logging to_stderr="on" debug="on">
> <logger_subsys subsys="CMAN" syslog_facility=".." debug="on"/>
> <logger_subsys subsys="CCS" syslog_facility=".." debug="on"/>
> </logging>
> </cluster>
>
> 2) as originally implemented by qdisk and rgmanager (and later by ccs):
>
> <cluster>
> <quorumd log_level="..." log_facility="...">
> <rm log_level="..." log_facility="...">
> </cluster>
>
> The 2 philosophies behind are fairly clear:
>
> #1 consider the logging as a subsystem on its own that should be
> configured as standalone bit.
>
> #2 consider the logging as part of the subsystem configuration bits.
>
> All the people involved in the discussion so far (Chrissie, Lon and me)
> don't really have a strong opinion on which way should be taken, but a
> decision needs to be taken. Both ways have pro and cons...
>
> #1
>
> Pros: it's elegant to see the configuration all in one place. Move away
> from subsystem keys to global ones. If the subsystem is an openais plugin,
> openais executive will do all the parsing for us with no code changes.
>
> Cons: the association between subystem and config is not immediate. Users
> need to remember mappings (CMAN == cman, CCS = ccs, etc.) that are not
> 1:1. There is no finegraned tuning for logging level.
>
> #2
>
> Pros: association is immediate between config and subsystem. 3 systems
> already use it.
> Cons: it's not centralized.
I maintain at least most of those 3. I agree that it's better from a
user-experience point of view (daemon X logs HERE), but it's also
fundamentally different from how liblogsys works, and doesn't easily
allow for sub-subsystem configuration.
For example, openais has several subsystems which (I think) can be
configured independently, but are all wrapped up in to one daemon.
Modeling this with the model rgmanager/qdiskd/etc. use is difficult.
I am having difficulty forming a clear opinion.
-- Lon
next prev parent reply other threads:[~2008-06-10 13:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-02 10:05 [Cluster-devel] [RFC] Configuring logging system for master Fabio M. Di Nitto
2008-06-10 13:19 ` Lon Hohberger [this message]
2008-06-10 15:06 ` 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=1213103943.20204.16.camel@ayanami.boston.devel.redhat.com \
--to=lhh@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).