Fix compatibility mode of backup jobs scheduling
authorMichał Dulko <michal.dulko@intel.com>
Wed, 16 Mar 2016 13:06:10 +0000 (14:06 +0100)
committerMichał Dulko <michal.dulko@intel.com>
Wed, 16 Mar 2016 13:25:39 +0000 (14:25 +0100)
commit128dacc6188d398dcd45ba4862243a8621f0d82f
tree75af3c95dd680c66ec97c409064f9609c8e1e78c
parent5e14671b6ee8b9055f048131bd3f9e5577494e9e
Fix compatibility mode of backup jobs scheduling

While testing interoperability of Liberty and Mitaka services I've found
two problems with backup jobs scheduling when running in non-scalable
mode (this happens when we run mixed Liberty and Mitaka c-bak services,
so during the live upgrade).

First of all when passing volume.host into scheduling we don't strip it
from backend and pool parts (@backend#pool), so in multi-backend
environment scheduling doesn't match backup host names and that clue is
silently ignored.

Second problem is that we don't pass the target volume's host into the
scheduling when restoring the volume. This means that we don't schedule
the jobs exactly the old way and it may happen that Liberty's
cinder-backup will receive restore request with a target volume he don't
have access to.

This commit sorts both problems out. Please note that this is very
low-risk, as it affects only this non-scalable mode, which without this
is broken anyway.

Change-Id: Ib7195f27a1e455732db8621cd09ba87daa5d5a33
Closes-Bug: 1558073
cinder/backup/api.py