Nova's rescue and unrescue assumes os-brick connect_volume is idempotent
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Triaged
|
High
|
Unassigned |
Bug Description
The rescue and unrescue operations in Nova assume that calls to `connect_volume` in os-brick are idempotent which it's currently true, but it was not something we guaranteed in os-brick.
With the recent CVE [1][2] we realized that os-brick cannot assume on the `connect_volume` that if there is a device/s present for the provided connection information then it is the right volume, and even if it's the right volume it cannot assume that it has the right information in sysfs (like the volume size), so it needs to clean things up to the best of its ability before actually connecting, and just in case it needs to confirm just before returning a patch to the caller that the device it's going to return is actually correct and consistent (as in the multipath only has devices with the same size and SCSI ID).
This means that os-brick's `connect_volume` will no longer be idempotent by design once this patch [3] merges to prevent data leak in any corner cases.
This will break the rescue and unrescue nova operations, because on the rescue call it stashes the original XML [4] and then unstashes it on unrescue [5], but in between Nova calls `connect_volume` for the rescue instance, effectively disconnecting the original device path.
This means that reusing that original path either points to a non-existent device or to a volume of another instance.
We can see an example of the non-existent device case in the failed CI job [6] where test `tempest.
libvirt.
[1]: https:/
[2]: https:/
[3]: https:/
setting this to high since changing this design block https:/ /review. opendev. org/c/openstack /os-brick/ +/882841 from merging which blocks fully resolving https:/ /bugs.launchpad .net/nova/ +bug/2004555