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 personally vote for 2 (it makes more sense in my head). Please cast your
vote by the end of this week.
Thanks
Fabio
PS the subsystems that will migrate, will also retain a compat layer etc.
--
I'm going to make him an offer he can't refuse.
