Skip to content

Conversation

github-actions[bot]
Copy link

This PR contains a snapshot of yoga from upstream.

notartom and others added 4 commits April 30, 2022 12:58
When the libvirt driver does live migration rollback of an instance
with network interfaces, it unconditionally refers to
migrate_data.vifs. These will only be set when Neutron has the
multiple port bindings extension. We don't handle the case of the
extension not being present, and currently the rollback will fail with
a "NotImplementedError: Cannot load 'vifs' in the base class" error.

Related-bug: 1969980
Change-Id: Ieef773453ed9f3ced564c1a352fbefbcc6a653ec
(cherry picked from commit 5181bae)
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
Ia1da21577d859885838de10110dd473f72af285d (db: Trivial rewrapping of
warning filters) is not in Yoga.

Change-Id: I63208c7bd5f9f4c3d5e4a40bd0f6253d0f042a37
Signed-off-by: Stephen Finucane <sfinucan@redhat.com>
(cherry picked from commit 8142b9d)
@github-actions github-actions bot requested a review from a team as a code owner April 10, 2023 08:20
@github-actions github-actions bot added automated Automated action performed by GitHub Actions synchronisation labels Apr 10, 2023
@markgoddard markgoddard merged commit 4c977e1 into stackhpc/yoga Apr 11, 2023
@markgoddard markgoddard deleted the upstream/yoga-2023-04-10 branch April 11, 2023 08:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automated Automated action performed by GitHub Actions synchronisation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants