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
[email protected]
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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
