On 12/12/2014 08:54 PM, melanie witt wrote:
Hi everybody,

At some point, our db archiving functionality got broken because there was a 
change to stop ever deleting instance system metadata [1]. For those 
unfamiliar, the 'nova-manage db archive_deleted_rows' is the thing that moves 
all soft-deleted (deleted=nonzero) rows to the shadow tables. This is a 
periodic cleaning that operators can do to maintain performance (as things can 
get sluggish when deleted=nonzero rows accumulate).

The change was made because instance_type data still needed to be read even after 
instances had been deleted, because we allow admin to view deleted instances. I saw a bug 
[2] and two patches [3][4] which aimed to fix this by changing back to soft-deleting 
instance sysmeta when instances are deleted, and instead allow 
read_deleted="yes" for the things that need to read instance_type for deleted 
instances present in the db.

My question is, is this approach okay? If so, I'd like to see these patches 
revive so we can have our db archiving working again. :) I think there's likely 
something I'm missing about the approach, so I'm hoping people who know more 
about instance sysmeta than I do, can chime in on how/if we can fix this for db 
archiving. Thanks.

I looked briefly into tackling this as well a while back. The tricky piece that I hit is what system_metadata should be available when read_deleted='yes'. Is it okay for it to be all deleted system_metadata or should it only be the system_metadata that was deleted at the same time as the instance? I didn't get to dig in enough to answer that.

Also there are periodic tasks that query for deleted instances so those might need to pull system_metadata in addition to the API.

[1] https://bugs.launchpad.net/nova/+bug/1185190
[2] https://bugs.launchpad.net/nova/+bug/1226049
[3] https://review.openstack.org/#/c/110875/
[4] https://review.openstack.org/#/c/109201/

melanie (melwitt)

OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to