nova/releasenotes/notes/nova-manage-placement-heal-allocations-13a9a0a3df910e0b.yaml
Matt Riedemann 95106d2fa1 Add nova-manage placement heal_allocations CLI
This adds a new CLI which will iterate all non-cell0
cells looking for instances that (1) have a host,
(2) aren't undergoing a task state transition and
(3) don't have allocations in placement and try
to allocate resources, based on the instance embedded
flavor, against the compute node resource provider
on which the instance is currently running.

This is meant as a way to help migrate CachingScheduler
users off the CachingScheduler by first shoring up
instance allocations in placement for any instances
created after Pike, when the nova-compute resource
tracker code stopped creating allocations in placement
since the FilterScheduler does it at the time of
scheduling (but the CachingScheduler doesn't).

This will be useful beyond just getting deployments
off the CachingScheduler, however, since operators
will be able to use it to fix incorrect allocations
resulting from failed operations.

There are several TODOs and NOTEs inline about things
we could build on top of this or improve, but for now
this is the basic idea.

Change-Id: Iab67fd56ab4845f8ee19ca36e7353730638efb21
2018-06-01 18:45:10 -04:00

19 lines
1.0 KiB
YAML

---
other:
- |
A new ``nova-manage placement heal_allocations`` CLI has been added to
help migrate users from the deprecated CachingScheduler. Starting in
16.0.0 (Pike), the nova-compute service no longer reports instance
allocations to the Placement service because the FilterScheduler does
that as part of scheduling. However, the CachingScheduler does not create
the allocations in the Placement service, so any instances created using
the CachingScheduler after Ocata will not have allocations in Placement.
The new CLI allows operators using the CachingScheduler to find all
instances in all cells which do not have allocations in Placement and
create those allocations. The CLI will skip any instances that are
undergoing a task state transition, so ideally this would be run when
the API is down but it can be run, if necessary, while the API is up.
For more details on CLI usage, see the man page entry:
https://docs.openstack.org/nova/latest/cli/nova-manage.html#placement