When forcing a host during live migration, conductor bypasses
the scheduler so the scheduler won't create an allocation in
Placement against the destination host.
With change Ia93168b1560267178059284186fb2b7096c7e81f, once all
computes are upgraded to Pike, the computes won't auto-heal the
allocations for their respective nodes either, so we end up with
no allocation for the destination node during a live migration when
the host is forced.
This change makes conductor use the source compute node allocations
for the instance to claim the same resource amounts on the forced
destination host in Placement. If the claim fails, a
MigrationPreCheckError is raised.
This is a short-term fix for Pike. A longer-term fix to avoid this
duplication with the scheduler is to have conductor call the
scheduler even when force=True but pass a flag to the scheduler
so it skips the filters but still makes the claim on the destination
node.
Finally, some comments are left in the live_migrate method in the
compute API code since this is all tightly-coupled between the
API and conductor when a host is specified in the request, and it's
easy to get lost on what the API is doing to the request spec which
changes how conductor behaves, i.e. if it calls the scheduler or not.
Change-Id: I40b5af5e85b1266402a7e4bdeb3705e1b0bd6f3b
Closes-Bug: #1712008
Live migration now seems to be failing, as after the movement of the VM,
the allocations are both present on the source host, and on the
destination host.
The related assertions are commented out and replaced with wrong ones to
make the test pass.
Change-Id: Ib15d34c8da14dd006a0782e325d3c5e7b83fd0f1
Related-Bug: #1712045
Forced live migration now seems to be failing, as after the movement of
the VM, the allocations are only present on the source host, and not on
the destination host.
The related assertions are commented out and replaced with wrong ones to
make the test pass.
Related-Bug: #1712008
Change-Id: I6856f57426db6f2f49daea86679b50d5d019fe19
Per comments in I6815958b2533d462a2e5d27e7be57440d9f4f40a and
I5fdafd9f6cf07a19bf86a6343663dad410887dcb.
Part of bp: doc-migration
Change-Id: Iac833503b57386ab91fa86f8c48f0dd8039e5922
Fix test_validate_volume_no_mtab_entry. Currently depends on /etc/mtab,
this patches and mocks psutil.disk_partitions, which is the source of
the dependency.
Change-Id: Ie10b134a1840b1277c0c4059f634a6bafd256c2d
Closes-Bug: #1708196
it's apparently too late to make this change in Pike rc stage
so defer to Queens by changing the release version.
Change-Id: I006f41383dcef68d63a646665a56cbd4c3f93c4b
Periodic task _cleanup_running_deleted_instances() looks for orphaned
and running instances on hypervisor that should be deleted.
The problem is it checks if running instance has the same
hypervisor defined as it is in nova database.
In bug #1285000 it has been found that removing instance during
its migration could lead to abandon instance files on destination
host.
This change removes host filter in _running_deleted_instances() to
find also orphaned instances that are running on 'post migration'
destination host.
Change-Id: Idd1b58b85329b8e021eba4bc27f577af1b3338f4
Partial-Bug: #1285000
There are some small comments on the review of
Ib2b49f70c55311195535a5ef250ff555e227fa0a
This is a follow-up for these comments.
Change-Id: I1d2d95a0864578161a34084db31eb460e895c1ec
FilterScheduler is the only scheduler driver that properly integrated
with placement api so this patch changes the functional test environment
to use the FilterScheduler instead of the ChanceScheduler.
The amount of vcpu the SmallFakeDriver reports need to be bumped to 2
as during resize to same host the filter scheduler doubles the
allocation on the host. Simply relying on the 16.0 default allocation
ratio does not work as the max_unit of the vcpu does not use the
allocation ratio to avoid that a single server overallocates the cpu.
The only change in unit test is
test_create_instance_with_oversubscribed_cpu which also loads the
SmallFakeDriver and asserts available resources on it.
Change-Id: I12de2e195022593ea2a3e2894f2c3b5226930d4f
Resource tracker doesn't clean up the resources of an instance after
it is offloaded since Ia93168b1560267178059284186fb2b7096c7e81f. So
this patch proposes an explicit cleanup in compute manager.
Closes-Bug: #1710249
Change-Id: Ib16e987d50162a4c11a31692704859b981915bed
The following 3 scenarios are covered by this patch:
* boot, shelve, unshelve, delete
* boot, shelve, shelve offload, unshelve on different host, delete
* boot, shelve, shelve offload, unshelve on the same host, delete
The second and the third scenarios are faulty and therefore those
test cases now assert the wrong behavior but contain the expected
behavior as commented out asserts.
Change-Id: Iaf88f8802a456d5e197b65405fa6959a2c514325
Related-Bug: 1710249
After evacuation the instance has allocations on both the source and
the destination computes. This is OK as the source compute is down.
However after the source compute is brought up the allocation from
the source host needs to be cleaned up.
Closes-Bug: #1709902
Change-Id: I0df401a7c91f012fdb25cb0e6b344ca51de8c309
If merge_resources results in a class of resource with a value of zero,
and that result is then used to form an allocation request, the
allocation will be rejected: the json schema for allocations requires
the value of a resource class to be at least 1.
Therefore merge_resources is changed so that anywhere the value is zero
in the results, that key is popped from the dict. We need to do it in
this way because we are modifying an existing dict, not returning a new
one that we are assembling.
Change-Id: Idea9315d6bce8b341f0c3d2dc0accca6ac259587
Closes-Bug: #1710908
Jenkins