cbe5f86ce7
... 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
15 lines
689 B
YAML
15 lines
689 B
YAML
---
|
|
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.
|