yahoo-eng-team team mailing list archive

[Balazs Gibizer <2097360@xxxxxxxxxxxxxxxxxx>]

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