Shared storage providers are not supported and will break things if used
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Medium
|
Unassigned |
Bug Description
https:/
There are at least two major issues with this:
1. On upgrade from Queens, any existing allocations against the compute node provider's DISK_GB inventory will not allow removal of the DISK_GB inventory from the compute node provider during the update_
2. During a move operation, we move the instance's allocations from the source compute node provider to the migration record, then go through the scheduler to pick a dest host for the instance and allocate resources against the dest host (and optionally shared storage provider). So:
a) The DISK_GB allocation from the instance to the shared storage provider is deleted for a short window of time during scheduling until we pick a dest host.
b) If cold migrate fails or is reverted, we delete the allocations (created by the scheduler) and move the allocations from the migration record (against the source node provider) back to the instance, but because we failed to move the DISK_GB allocation against the sharing provider for the instance to the migration record, we've lost that DISK_GB allocation when copying it back to the instance on revert/failure:
--
We could also have issues with how forced live migrate:
And evacuate:
bypass the scheduler altogether so we're potentially not handling shared provider allocations there either.
Also, we don't have *any* shared storage provider CI jobs setup. A start to that is here:
https:/
But that's just a single-node job at the moment and we'd need a multi-node shared storage CI job to really say we support shared storage providers as a feature in nova.
Related fix proposed to branch: master /review. openstack. org/586614
Review: https:/