[openstack-dev] [nova] nova-manage db archive_deleted_rows broken
mriedem at linux.vnet.ibm.com
Tue Dec 16 20:18:54 UTC 2014
On 12/12/2014 7: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 . 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  and two patches  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.
>  https://bugs.launchpad.net/nova/+bug/1185190
>  https://bugs.launchpad.net/nova/+bug/1226049
>  https://review.openstack.org/#/c/110875/
>  https://review.openstack.org/#/c/109201/
> melanie (melwitt)
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
I changed this from In Progress to Confirmed, removed Alex as the owner
(since I didn't see any patches from him) and marked it High:
It looks like that could be a duplicate of bug
https://bugs.launchpad.net/nova/+bug/1183523 which sounds like a lot of
the same problems. dripton had looked at it at one point and said it was
Won't Fix at that time, but I don't think that's the case. Note comment
7 in there:
"comstud thinks we can fix this but we need to do instance_type data
differently. Maybe embedded JSON blobs so we have all the information we
need without a reference to the instances row. (My opinion: yuck.) So
this bug is staying open for now, but it requires some significant
redesign to fix."
I'm not sure if that's related to comstud's instance_type design summit
topic in Atlanta or not, it sounds the same:
I can't find the etherpad for that. I'm wondering if Dan Smith's
blueprint for flavor-from-sysmeta-to-blob handles that?  I've never
been sure how those two items are related.
Anyway, I think the fix is for the taking assuming someone has a good
fix. As noted in one of the bugs, the foreign key constraints in nova
don't have cascading deletes, so if it's a foreign key issue, we should
find the one that's not being cleaned up before the delete. It looked
like dripton thought it was fixed_ips at one point:
More information about the OpenStack-dev