#174 Issue closed: DRBD layout restoration needs to be reviewed

dragon299 opened issue at 2012-11-06 10:22:

I had problems while trying to restore my drbd system. In my opinion this part of rear should be reviewed.

Lets have a look on (line 21 to 34):
/usr/share/rear/layout/prepare/GNU/Linux/15_include_drbd_code.sh

ask if we need to become primary

read 2>&1 -p "Type \"Yes\" if you want DRBD resource $resource to become primary: "
if [ "$REPLY" = "Yes" ] ; then
    cat >> $LAYOUT_CODE <<EOF

# We assume DRBD on LVM
drbdadm attach $resource
drbdadm -- --overwrite-data-of-peer primary $resource
EOF
else
cat >> $LAYOUT_CODE <<EOF

LVM on DRBD

drbdadm up $resource
EOF

  1. Issue
    The request if drbd should become primary is case sensitive. I think this is a usability problem.
  2. Issue
    I don't understand why a primary drbd means that we can assume drbd on lvm? Its the other way around in my opinion.
    If we type "Yes", in most cases we have LVM on DRBD and then we need the command "drbdadm up $resource". If we type something else, we do not have LVM or something else on DRBD and we only use "drbdadm attach $resource".

jhoekx commented at 2012-11-06 14:29:

Your issue 1. is deliberate. It's like that in all of ReaR. We should probably make things consistent though.

Issue 2 looks like it needs review indeed. The comments are leftovers from 2 years ago. The decision to become master is not related to if we have LVM on top of it or not... I don't have access to a DRBD setup right now to test, but we have plans for automated testing of ReaR and will include it then.

If you can't wait and can fix it yourself, we'll gladly take pull requests!

[Export of Github issue for rear/rear.]