Public bug reported: This is a follow up of https://bugs.launchpad.net/nova/+bug/2097359. That bug is fixed by ensuring that the data migration to InstanceNUMACell ovo from 1.4 to 1.5 (or 1.6) happens correctly during the load of the InstanceNUMACell from the DB by not just moving the data to the new pcpuset field but also bumping the object version in the DB from 1.4 to 1.5 (or 1.6). However if the related nova-compute running pre-Victoria version (the new pcpuset field added in Victoria as ovo version 1.5) and the compute updates the instance in the DB (e.g. after an instance state change during reboot) the compute sends the backlevelled 1.4 object back to the conductor and conductor saves that 1.4 version to the DB. Then later when the data is loaded for any reasons the data migration runs again and updates the data in the DB to the 1.5 (or 1.6) version. This causes a ping pong of the data version (and content) in the DB while the pre-Victoria compute is in the cluster managing the instance.
While this does not cause any known data loss or instance lifecycle issue (after https://bugs.launchpad.net/nova/+bug/2097359 has been fixed) it is generating unnecessary DB write operations. The root cause of the issue is that the data migration only runs during data loading from the DB and does not consider when old version of the ovo is received from an old compute. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2097360 Title: The InstanceNUMACell related content of instance_extra.numa_topology field constantly changing between version 1.4 and version1.6 while pre Victoria compute is running Status in OpenStack Compute (nova): New Bug description: This is a follow up of https://bugs.launchpad.net/nova/+bug/2097359. That bug is fixed by ensuring that the data migration to InstanceNUMACell ovo from 1.4 to 1.5 (or 1.6) happens correctly during the load of the InstanceNUMACell from the DB by not just moving the data to the new pcpuset field but also bumping the object version in the DB from 1.4 to 1.5 (or 1.6). However if the related nova-compute running pre-Victoria version (the new pcpuset field added in Victoria as ovo version 1.5) and the compute updates the instance in the DB (e.g. after an instance state change during reboot) the compute sends the backlevelled 1.4 object back to the conductor and conductor saves that 1.4 version to the DB. Then later when the data is loaded for any reasons the data migration runs again and updates the data in the DB to the 1.5 (or 1.6) version. This causes a ping pong of the data version (and content) in the DB while the pre-Victoria compute is in the cluster managing the instance. While this does not cause any known data loss or instance lifecycle issue (after https://bugs.launchpad.net/nova/+bug/2097359 has been fixed) it is generating unnecessary DB write operations. The root cause of the issue is that the data migration only runs during data loading from the DB and does not consider when old version of the ovo is received from an old compute. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2097360/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
