Description of problem: I am not fully certain about the details. Didn't try this myself, only got a report about a single system. engine-backup --mode=verify fails on backups taken on it, with: legacy kerberos/ldap directory integration was in use. Please migrate to ovirt-engine-extension-aaa-ldap and backup/restore again This happens because due to a somewhat-weird sequence of events, systems that had such a legacy setup and upgraded to 4.0, still have a vdc option 'DomainName', which is what engine-backup checks for when deciding to fail as above. The option value should be empty, though, so a fix can be to fail only if it's not empty. Or we can decide that we can ignore it altogether in 4.2 (and 4.1), because it's irrelevant anymore. So flow should be, more-or-less: 1. setup a 3.6 engine 2. configure a legacy kerberos/ldap directory 3. upgrade to 4.0 (should be done by a backup/restore, moving from el6 to el7) 4. upgrade to 4.1 (and 4.2 if you want) 5. engine-backup --mode=backup --file=f1 --log=backup.log 6. engine-backup --mode=verify --file=f1 --log=verify.log
A workaround: Manually delete the option. Connect to the engine database and run: select fn_db_delete_config_value('DomainName','general');
Severity...?
(In reply to Yaniv Kaul from comment #2) > Severity...? Not sure it's even worth fixing, perhaps it's enough that we have it documented. This is because AFAIK we never use directly 'engine-backup --mode=verify' (except for in CI, where it's "controlled"), nor do we tell users to do this. Setting low for now.
(In reply to Yedidyah Bar David from comment #3) > (In reply to Yaniv Kaul from comment #2) > > Severity...? > > Not sure it's even worth fixing, perhaps it's enough that we have it > documented. This is because AFAIK we never use directly 'engine-backup > --mode=verify' (except for in CI, where it's "controlled"), nor do we tell > users to do this. > > Setting low for now. Shouldn't we add instructions to actually run verify after backup?
(In reply to Yaniv Kaul from comment #4) > Shouldn't we add instructions to actually run verify after backup? Of course, generally speaking. In practice not sure how much this is worth. IIRC it was added in the 3.6->4.0 upgrade/migration days, mainly to let the user know earlier (before engine-setup) that the old db has 4.0-incompatible data, specifically legacy kerbldap... Of course we also verify that the content is not corrupted, which is not that relevant if you do this immediately (unless your machine is severely broken). I guess most backup software verifies (optionally, if at all) by read-after-write from the target long-term backup medium. Not sure exactly how to apply this to engine-backup or our docs, but we can.
*** Bug 1583198 has been marked as a duplicate of this bug. ***
Not critical, we do not have a large user base for 3.6 anymore and the docs are clear.
(In reply to Yaniv Lavi from comment #7) > Not critical, we do not have a large user base for 3.6 anymore and the docs > are clear. This is not relevant for existing 3.6 customer only. But IIUC it's relevant for all customers who used to have legacy AAA in the past and used to have 3.6 env. Something did not remove this from DB and thus it caused verification of the backup to fail on 4.1/4.2. Thus IMO engine-setup should remove such record from DB automatically.
What Jiri said. I agree with Yaniv it's not critical, but only because no-one uses mode=verify. Also, not sure engine-setup should remove it - it's already empty. Leaving closed - not critical and we have a workaround.