[Cluster-devel] [RFC] Configuring logging system for master

[Cluster-devel] [RFC] Configuring logging system for master

[Fabio M. Di Nitto]

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.

[Cluster-devel] [RFC] Configuring logging system for master

[Lon Hohberger]

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

[Cluster-devel] [RFC] Configuring logging system for master

[Fabio M. Di Nitto]

On Tue, 10 Jun 2008, Lon Hohberger wrote:

>> #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.

So thinking for the future where we might have all our daemons switched 
into an openais set of plugins, Christine solution is for sure the best.

My only real main concern is the name mapping: CMAN vs cman etc. that 
might be addressed by just using a lower2upper case and let the user use 
normal subsystem names.

Switching ccs is of course trivial since we have no real release yet out 
there that is supported.

qdisk/rgmanager will need to have a compatibility layer.

Fabio

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