There is a race condition in nova-compute with the ironic virt driver as
nodes get rebalanced. It can lead to compute nodes being removed in the
DB and not repopulated. Ultimately this prevents these nodes from being
scheduled to.

The main race condition involved is in update_available_resources in
the compute manager. When the list of compute nodes is queried, there is
a compute node belonging to the host that it does not expect to be
managing, i.e. it is an orphan. Between that time and deleting the
orphan, the real owner of the compute node takes ownership of it ( in
the resource tracker). However, the node is still deleted as the first
host is unaware of the ownership change.

This change prevents this from occurring by filtering on the host when
deleting a compute node. If another compute host has taken ownership of
a node, it will have updated the host field and this will prevent
deletion from occurring. The first host sees this has happened via the
ComputeHostNotFound exception, and avoids deleting its resource
provider.

Co-Authored-By: melanie witt <melwittt@gmail.com>

Conflicts:
    nova/db/sqlalchemy/api.py

NOTE(melwitt): The conflict is because change
I9f414cf831316b624132d9e06192f1ecbbd3dd78 (db: Copy docs from
'nova.db.*' to 'nova.db.sqlalchemy.*') is not in Wallaby.

NOTE(melwitt): Differences from the cherry picked change from calling
nova.db.api => nova.db.sqlalchemy.api directly are due to the alembic
migration in Xena which looks to have made the nova.db.api interface
obsolete.

Closes-Bug: #1853009
Related-Bug: #1841481

Change-Id: I260c1fded79a85d4899e94df4d9036a1ee437f02
(cherry picked from commit a8492e88783b40f6dc61888fada232f0d00d6acf)

We started storing NUMA information as objects in the database in Kilo
(commit bb3202f8594). Prior to this, we had stored this NUMA information
as a plain old dict. To facilitate the transition, we provided some
handlers based on these '_from_dict' functions. There were used to
ensure we could load old-style entries, converting them to objects which
we could later save back to the database.

It's been over four years (three since Kilo went EOL) and nine (nearly
ten) releases, meaning its time to look at dropping this code. At this
point, the only thing that could hurt us is attempting to do something
with a NUMA-based instance that hasn't been touched since they were
first booted on a Kilo or earlier host. Convert the '_to_dict'
functionality and overrides of the 'obj_from_primitive' method with a
similar check in the DB loading functions. Crucially, inside these DB
loading functions, save back when legacy objects are detected. This is
acceptable because the 'update_available_resource' in the resource
tracker pulls out both compute nodes and instances, with their embedded
fields like 'numa_topology', ensuring this will be run as part of the
periodic task.

NOTE: We don't need to worry about migrations of 'numa_topology' fields
in other objects: the 'RequestSpec' and 'MigrationContext' objects were
added in Liberty [1][2] and used the 'InstanceNUMATopology' o.vo from
the start, while the 'NUMATopology' object has only ever been used in
the 'ComputeNode' object.

Change-Id: I6cd206542fdd28f3ef551dcc727f4cb35a53f6a3
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>

Change-Id: I6381365ff882cf23808e8dabfce41143c5e35192
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>

This patch adds a function, get_compute_nodes_by_host_or_node() to
the host manager to get ComputeNode objects by the given host name
and/or by the given node name.

Change-Id: Ic492766691741e3a8e4938ad90307cb2fe484cc5
Blueprint: use-placement-in-tree

The unit test for ComputeNode.obj_make_compatible() made two mistakes:
* they asserted that a field is not in the primitives, but primitives
  is a dict where the top level keys are nova.object_data,
  nova.object_version, ... etc. So the assertNotIn call was succeded
  false positively.
* they did not always initialized the tested field in the ComputeNode
  object if a field is not initialized then it is never in the
  primitives.

This patch fixed the unit tests but in the meantime it is uncovered that
some of the compatibility code was missing from the ComputeNode ovo. So
those are also added now.

Change-Id: I2010f12b591dff381597c577920738712093e4ce

This patch adds an online data migration script to process the
ratio with 0.0 or None value.

If it's an existing record with 0.0 values, we'd want to do what
the compute does, which is use the configure ``xxx_allocation_ratio``
config if it's not None, and fallback to using the
``initial_xxx_allocation_ratio`` otherwise.

Change-Id: I3a6d4d3012b3fffe94f15a724dd78707966bb522
blueprint: initial-allocation-ratios

This patch adds an online data migrations for any compute_nodes
with existing ``0.0`` and ``None`` allocation ratio. If it's an
existing record with 0.0 values, we will replace it with the
configure ``xxx_allocation_ratio`` config if it's not None, and
fallback to using the ``initial_xxx_allocation_ratio`` otherwise.

Change-Id: Ic137d837c7b1d29f56a45a01b3b104d6d2c698df
blueprint: initial-allocation-ratios

This patch including 2 changes:
1. Change the default values for
CONF.(cpu|ram|disk)_allocation_ratio to ``None``

2. Change the resource tracker to overwrite the compute node's
allocations ratios to the value of the XXX_allocation_ratio if
the value of these options is NOT ``None`` or ``0.0``.

The "0.0" condition is for upgrade impact, and it will be
removed in the next version (T version).

Change-Id: I6893d63dc5f29bc2eb348fe0aa9fbc8490e6eb40
blueprint: initial-allocation-ratios

Change Ia69fabce8e7fd7de101e291fe133c6f5f5f7056a sets the
ComputeNode.uuid to whatever the virt driver reports if the
virt driver reports a uuid, like in the case of ironic.

However, that breaks upgrades for any pre-existing compute
node records which have a random uuid since ComputeNode.uuid
is a read-only field once set.

This change simply ignores the uuid from the virt driver
resources dict if the ComputeNode.uuid is already set.

The bug actually shows up in the ironic grenade CI job
logs in stable/rocky but didn't fail the nova-compute startup
because ComputeManager._update_available_resource_for_node()
catches and just logs the error, but it doesn't kill the service.

Change-Id: Id02f501feefca358d36f39b24d426537685e425c
Closes-Bug: #1798172

Fix ComputeNodeList.get_all_by_uuids() to use model_query() so that
deleted compute nodes are filtered from the results. Without this,
a stale result from placement could cause us to choose a compute
node as a scheduling destination that has since been deleted.

Change-Id: I811e84af46d678c3fdbf94ee400eabe659fc3d4e
Closes-Bug: #1793533