Nova: data base archiving doesn't store data to shadow_instances. Description: ------------ When deleting instance it's "deleted" records remains exist under 'instances' main table, this "deleted" data doesn't being transfer to shadow_instances after running - 'nova-manage db archive_deleted_rows 10000000'. Scenario: --------- 1) Create new instance. 2) Delete instance 3) Run data base archiving (By: 'nova-manage db archive_deleted_rows 10000000'). 4) Check the 'shadow_instances' table in the DB . (By: 'mysql -u root nova -e "select * FROM shadow_instances";') Results: --------- The shadow_instances table will remain empty after delete instances and running 'nova-manage db archive_deleted_rows 1000'
This is mine since I wrote db_archiving.
I improved the unit tests to try to reproduce this bug in a systematic way. See https://review.openstack.org/28558 for the patch. Unfortunately the bug (which definitely happens on Omri's box) doesn't show up in the unit test -- the instances table gets archived properly. I suspect the bug revolves around foreign key constraints. instances probably aren't getting archived because they're a foreign key for some other table that needs to get archived first. Things should still work in that case (we catch the IntegrityError, and later the other table should get archived, and still later we should retry the instances table and it'll then work), but maybe we have circular foreign key dependencies or something. Still hunting.
Moving from RDO to RHOS, because this will affect RHOS 3.0 as well.
This is also https://bugs.launchpad.net/nova/+bug/1183523 It's not a bug in db-archiving. It's a bug (or perhaps feature) in the way we incompletely delete instances, leaving references to the "deleted" instance's uuid in other tables. (instance_system_metadata and fixed_ips in this simple test, but there are 6 other tables which can potentially have the same issue). It's easy enough to just start cascade deleting everything that refers to the instance when we delete the instance, but that makes restoring a deleted instance harder.
Another case that pins the instances rows was just added. Details in the upstream bug. It's going to take serious upstream redesign to fix this. We're not marking this WONTFIX but don't hold your breath waiting for the solution either. Luckily, instances rows are pretty small, so db-archiving is still cleaning up 99%+ of the deleted rows. It's still doing its job. Just not as tidily as we'd like.
Marking this WONTFIX. The upstream bug is still open, but it will take significant re-architecting to allow us to actually delete the instances row and all the rows in other tables that point to it, and that won't happen in the Havana timeframe. Maybe in Icehouse if I can interest any core contributors.
The bug has been fixed upsteam : https://bugs.launchpad.net/nova/+bug/1183523 https://review.openstack.org/299474 It will land in newton.