On 2006-01-26T12:06:33, Alan Robertson <[EMAIL PROTECTED]> wrote:
> >Four reasons:
> > - the CIB is intended to be policy free (and at the moment is IIRC)
> BUT this is a CIB policy - hence it must be enforced and carried out by
> the CIB.
>
> > - correct interpretation of options in the CIB requires linking against
> > the PE
> > (or worse, duplicating slabs of its code)
>
> I don't follow this at all. It's the CIB that writes the CIB, isn't it?
Yeah, but to the CIB, the data in the CIB is opaque. (Minus the
generation counters.)
Iff the CIB was to interpret itself, it would have to have the pengine
smarts to figure out which option actually applied at any given time.
I second Andrew's motion that this isn't a good idea from a design point
of view.
I second Alan's motion that the current solution ain't perfect yet
either. ;-) Ultimately, I want the logging system itself (ie, ha_logd
and cl_log.*) to have flags and different levels, so we can tune logging
at a much finer granularity.
ie, log everything with an importance of warn and up; comm layer info
and up; log all things related to communication with debug; log CIB
stuff at debug2.
Then you could easily say "config changes: yes, log them"...
Sincerely,
Lars Marowsky-Brée
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
