yahoo-eng-team team mailing list archive

[Balazs Gibizer <2097360@xxxxxxxxxxxxxxxxxx>]

After discussing this further the DB write amplification happens in the
very specific time window where pre Victoria computes running together
with Victoria control services. This happens during a rolling upgrade
and expected to only exists for a short time. Given that the how old is
the Victoria version I think it is better not to try to fix it. So I'm
closing this as won't fix.

** Changed in: nova
       Status: In Progress => Won't Fix

-- 
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):
  Won't Fix

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