Libvirt 7.7 changed the mdev device naming to include the parent PCI
device when listing node devices. The domain, however, will still only
see the UUID and not see the parent PCI device. Changing the parsing to
simply drop the PCI identifier is not enough as the device cannot be
found when attempting to lookup the new ID.

Modify the Libvirt Driver's _get_mediated_device_information to tolerate
different formats of the mdev name. This first uses the legacy behavior
by trying to lookup the device name that is passed in (typically
mdev_<uuid> format) and if that is not found, iterates the list of mdev
node devices until the right UUID is found and selects that one.

Note that the lookup of the mdev device by UUID are needed in order
to keep the ability to recreate assigned mediated devices on a reboot of
the compute node.

Additionally, the libvirt utils parsing method mdev_name2uuid, has
been updated to tolerate both mdev_<uuid> and mdev_<uuid>_<pciid>
formats.

Closes-Bug: 1951656

Change-Id: Ifed0fa16053228990a6a8df8d4c666521db7e329
(cherry picked from commit a28b907c4f0dbba6e141a8fbea807e6cb0438977)
(cherry picked from commit 98d8c9eaa3c415cc234193e6a9115db887751363)
(cherry picked from commit 28053917200e3e242148672efda0e1a2b043dc48)

Due to a new mdev naming, we can't parse it.

Change-Id: I0f785178b132dfef668829558dea9f7e674abadb
Related-Bug: #1951656
(cherry picked from commit 185201974775bab966f4e5ca3bbdc31b8269fa4c)
(cherry picked from commit 857df72d3166a8f7e8a8cdfeabb62ad6ead46565)
(cherry picked from commit 71aa17a487136be5e938192857721d9119222811)

We have all the weighers enabled by default and each can have its own
multiplier making the final compute node order calculation pretty
complex. This patch adds some debug logging that helps understanding how
the final ordering was reached.

Change-Id: I7606d6eb3e08548c1df9dc245ab39cced7de1fb5
(cherry picked from commit 154ab7b2f9ad80fe432d2c036d5e8c4ee171897b)

Resolving the following SAWarning warnings:

  Coercing Subquery object into a select() for use in IN(); please pass
  a select() construct explicitly

  SELECT statement has a cartesian product between FROM element(s)
  "foo" and FROM element "bar". Apply join condition(s) between each
  element to resolve.

While the first of these was a trivial fix, the second one is a little
more involved. It was caused by attempting to build a query across
tables that had no relationship as part of our archive logic. For
example, consider the following queries, generated early in
'_get_fk_stmts':

  SELECT instances.uuid
  FROM instances, security_group_instance_association
  WHERE security_group_instance_association.instance_uuid = instances.uuid
    AND instances.id IN (__[POSTCOMPILE_id_1])

  SELECT security_groups.id
  FROM security_groups, security_group_instance_association, instances
  WHERE security_group_instance_association.security_group_id = security_groups.id
    AND instances.id IN (__[POSTCOMPILE_id_1])

While the first of these is fine, the second is clearly wrong: why are
we filtering on a field that is of no relevance to our join? These were
generated because we were attempting to archive one or more instances
(in this case, the instance with id=1) and needed to find related tables
to archive at the same time. A related table is any table that
references our "source" table - 'instances' here - by way of a foreign
key. For each of *these* tables, we then lookup each foreign key and
join back to the source table, filtering by matching entries in the
source table. The issue here is that we're looking up every foreign key.
What we actually want to do is lookup only the foreign keys that point
back to our source table. This flaw is why we were generating the second
SELECT above: the 'security_group_instance_association' has two foreign
keys, one pointing to our 'instances' table but also another pointing to
the 'security_groups' table. We want the first but not the second.

Resolve this by checking if the table that each foreign key points to is
actually the source table and simply skip if not. With this issue
resolved, we can enable errors on SAWarning warnings in general without
any filters.

Conflicts:
    nova/tests/fixtures/nova.py

NOTE(melwitt): The conflict is because change
I63f57980e01f472a25821790610f0836f1882a7f (tests: Restore - don't reset
- warning filters) is not in Xena.

Change-Id: I63208c7bd5f9f4c3d5e4a40bd0f6253d0f042a37
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
(cherry picked from commit 8142b9dc47b7096ab9d8180f0b5b1e52d513e2dc)
(cherry picked from commit ce2cc54bfe236554badb9f6bf53a958417e5525d)