On 8/20/07, Andreas Kurz <[EMAIL PROTECTED]> wrote: > On 8/20/07, Andrew Beekhof <[EMAIL PROTECTED]> wrote: > > On 8/20/07, Andreas Kurz <[EMAIL PROTECTED]> wrote: > > > Hello all, > > > > > > I was just looking for the default values for the "prereq" and > > > "on_fail attribute" of operations in the crm.dtd shipped with > > > Heartbeat v2.1.2 ... whithout success: > > > ... > > > prereq (nothing|quorum|fencing) #IMPLIED > > > on_fail (ignore|block|stop|restart|fence) #IMPLIED> > > > > it depends on what the operation is and whether you have stonith enabled > > > > on_fail: > > most default to 'restart' except 'stop' which defaults to 'block' if > > stonith is not enabled and 'fence' if it is. > > > > prereq: > > resources with type=stonith default to 'nothing'. > > for everything else, they default to 'fencing' if that is enabled or > > 'quorum' if not. > > ok > > > > > > ... > > > > > > In Alan's latest tutorial I found that fencing/fence seem to be the > > > default values ... is that correct? > > > > > > Additionally Alan's tutorial does not list a "prereq" attribute for > > > operations but a meta-attribute called "start_prereq" for the > > > primitive ... a leftover from older heartbeat versions? > > > > correct > > > > > Wouldn't it be a nice feature to automatically include all default > > > values in the cib for attributes that are not set explicitly ... or > > > make it a configureable option to let heartbeat do that? > > > > well that would make it much larger and since some of the defaults > > depend on other aspects of the configuration, it would likely cause > > more problems than its worth > > Hmm ... so there is no way to get a quick overview of all currently > used default values for a running configuration ... without > investigating ptest output? I understand it is to much information to > keep in the running config but an extra option e.g. to 'ptest' that > gives a 'full' config could be quite useful IMHO.
the challenge is doing it in such a way that its useful but not horribly noisy. its worth pointing out that a lot of this logging used to exist but was removed for just this reason _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
