Open Stack

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 [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.
>
> [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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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:

https://bugs.launchpad.net/nova/+bug/1226049

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:

https://bugs.launchpad.net/nova/+bug/1183523/comments/7

"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:

http://junodesignsummit.sched.org/event/e3f1d51c53fc484d070f02ea36d08601#.VJCS6yvF-KU

I can't find the etherpad for that. I'm wondering if Dan Smith's 
blueprint for flavor-from-sysmeta-to-blob handles that? [1] 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:

https://review.openstack.org/#/c/32742/

[1] 
http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/flavor-from-sysmeta-to-blob.html

-- 

Thanks,

Matt Riedemann