Fix online upgrades for Bios/Traits

... And tags, but nobody uses tags since it is not available
via the API.

Anyhow, the online upgrade code was written under the assumption
that *all* tables had an "id" column. This is not always true
in the ironic data model for tables which started as pure extensions
of the Nodes table, and fails in particular when:

1) A database row has data stored in an ealier version of the object
2) That same object gets a version upgrade.

In the case which discovered this, BIOSSetting was added at version
1.0, and later updated to include additional fields which incremented
the version to 1.1. When the upgrade went to evaluate and iterate
through the fields, the command failed because the table was designed
around "node_id" instead of "id".

Story: 2010632
Task: 47590

Change-Id: I7bec6cfacb9d1558bc514c07386583436759f4df

1 files changed, 14 insertions, 0 deletions

diff --git a/releasenotes/notes/fix-online-version-migration-db432a7b239647fa.yaml b/releasenotes/notes/fix-online-version-migration-db432a7b239647fa.yaml
new file mode 100644
index 000000000..824185aab
--- /dev/null
+++ b/releasenotes/notes/fix-online-version-migration-db432a7b239647fa.yaml
@@ -0,0 +1,14 @@
+---
+fixes:
+  - |
+    Fixes an issue in the online upgrade logic where database models for
+    Node Traits and BIOS Settings resulted in an error when performing
+    the online data migration. This was because these tables were originally
+    created as extensions of the Nodes database table, and the schema
+    of the database was slightly different enough to result in an error
+    if there was data to migrate in these tables upon upgrade,
+    which would have occured if an early BIOS Setting adopter had
+    data in the database prior to upgrading to the Yoga release of Ironic.
+
+    The online upgrade parameter now subsitutes an alternate primary key name
+    name when applicable.