Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi,
I've succeeded at making drbd work as a master-slave resource in
heartbeat v2 now. So far, so good.
However, drbdadm makes it exceptionally hard and annoying to parse its
output, which means I end up having to filter and post-process it
heavily, none of which is going to make it very easy to maintain the
scripts.
- The header printed when __DRBD_NODE__ is found in the environment is
totally useless.
- When asking drbdadm about the state of a resource not listed locally,
it prints warnings about the other resources. That's very annoying:
# drbdadm state r1 ; echo $?
/etc/drbd.conf:118: in resource r0, on node_0 { ... } ... on node_1 {
... }:
There are multiple host sections for the peer.
Maybe misspelled local host name 'xen-1'?
/etc/drbd.conf:1: in resource r0:
missing section 'on xen-1 { ... }'.
10
_Yes_, I know, because __DRBD_NODE__ is not going to be set here,
because I'm asking about a different resource!
- Even when this works, I get
xen-1:~ # __DRBD_NODE__=node_0 drbdadm state r1 ; echo $?
found __DRBD_NODE__ in environment
PRETENDING that I am >>node_0<<
'r1' not defined in your config.
wouldn't it be more consistent if this consisted of a single "Not
defined"?
- When the drbd module is not loaded, I get back a warning and exit code
20, shouldn't this be an "Not loaded"/"Not configured" as well?
- drbdadm doesn't propagate back error codes. Even when drbdsetup fails
(drbdadm primary, for example), it still exits with 0 - success.
ioctl(,SET_STATE,) failed: Permission denied
Partner is already primary
Command '/sbin/drbd setup /dev/drbd0 primary' terminated with exit code 20
drbdadm aborting
rc=0
- drbdadm disconnect seems to also demote a primary; I'd expect it to
just disconnect it from the secondary?
I already mailed about some of these to the -dev list on Date: Fri, 26
Jan 2007 16:24:08 +0100, but didn't receive any replies yet ...
I'm not clear how to proceed.
Some of these are clear bugs (ie, error propagation), but is drbdadm the
tool I should be using - in which case it probably needs to be made more
useful for scripting, maybe with a -q switch -, or do I need to call
drbdsetup directly, which would complicate my scripts in other ways?
Sincerely,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde