old nova instances cant be started on post victoria deployments
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
High
|
sean mooney |
Bug Description
Downstream we had an interesting but report https:/
Instances created after liberty but before victoria
that request a numa topology but do not have CPU pinning
cannot be started on post victoria nova.
as part of the
https:/
spec we started tracking cpus as PCVU and VCPU resource classes but since a given instance
would either have pinned cpus or floating cpus no changes too the instance numa topology object
were required.
with the introduction of mixed cpus in a single instnace
the instnace numa topology object was extended with a new pcpuset field.
as part of that work the _migrate_
https:/
for numa topologies that predate ovo
and
an new _migrate_
what we missed in the review is that unpinned guests should have had the cell.pcpuset set to the empty set
here
https:/
The new filed is not nullable and is not present in the existing json serialised object
as a result accessing cell.pcpuset on object returned form the db will raise a NotImplementedError because it is unset if the VM was created between liberty and victoria.
this only applies to non-pinned vms with a numa topology i.e.
hw:mem_
summary: |
- old nova instance cant be started on post victoria deployments + old nova instances cant be started on post victoria deployments |
we could argue if this is high or median because its been sooooo long since this regression was introduced and it does not impact newly created vms on anything Victoria or later.
but for people that have an older cloud this bug still technically exits in master if you are moving from something ancient to more recent.