Comment 2 for bug 1851310

Revision history for this message
Fuel Devops McRobotson (fuel-devops-robot) wrote : Fix merged to openstack/nova (9.0/mitaka)

Reviewed: https://review.fuel-infra.org/41521
Submitter: Pkgs Jenkins <email address hidden>
Branch: 9.0/mitaka

Commit: 6b6a602a0dbfa4ab33b6cfe2a4a7e481182a87a7
Author: Brent Tang <email address hidden>
Date: Mon Nov 11 15:54:24 2019

Instance obj_clone leaves metadata as changed

When performing an obj_clone on an Instance object, it relies on the
base obj_clone's deep copy method which just goes through all of the
fields and duplicates them on the clone. However, the Instance object
has internal tracking attributes for metadata and system_metadata that
keep track of which keys have changed. Since these don't get copied
over on the deep copy, these will show up as having changed on the
cloned Instance (if they had metadata set originally) and on a save
on this cloned object will end up updating the metadata in the db
which if these have stale information will wipe out other changes.

Such a scenario to this is occurring during build_instance where the
Claim constructor is saving off a clone of the Instance object
so that it will have the current copy. In the case of a failure
during the build_instance, the claim will use this current copy
to then set the value of the host on the instance to None. Since
the clone reflects that the system_metadata has changed, it will
as part of the save try to update the system_metadata in the db,
which since it is stale will wipe out changes made.

In the case of the issue being fixed here, the value in the
system_metdata being wiped out is the network_allocated=True
attribute. By this being wiped out then reschedules of that
build_instance fail in cases where the IP address has been
assigned to the instance.

Change-Id: Ie49a90993fb9643c04d75402dbaaa933c6b5222e
Closes-Bug: #1851310