From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lon Hohberger <lhh@redhat.com>
Date: Tue, 10 Jun 2008 09:19:03 -0400
Subject: [Cluster-devel] [RFC] Configuring logging system for master
In-Reply-To: <Pine.LNX.4.64.0806021102280.5892@trider-g7>
References: <Pine.LNX.4.64.0806021102280.5892@trider-g7>
Message-ID: <1213103943.20204.16.camel@ayanami.boston.devel.redhat.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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