Description of problem: Since we're using nova_cell0 instead of nova database, nova-manage db archive_deleted_rows is no longer archiving deleted rows nova-manage db archive_deleted_rows --verbose --max_rows 1000000 Version-Release number of selected component (if applicable): # rpm -qa|grep nova python-nova-17.0.5-3.d7864fbgit.el7ost.noarch openstack-nova-api-17.0.5-3.d7864fbgit.el7ost.noarch puppet-nova-12.4.0-6.el7ost.noarch openstack-nova-common-17.0.5-3.d7864fbgit.el7ost.noarch python2-novaclient-10.1.0-1.el7ost.noarch How reproducible: Always Steps to Reproduce: 1. Get 705k deleted instances 2. run nova-manage db archive_deleted_rows 3. Actual results: Nothing is archived Expected results: All rows should be achived up to --max_rows Additional info:
MariaDB [nova_cell0]> select count(*) from instances where deleted_at is not null; +----------+ | count(*) | +----------+ | 708405 | +----------+
We do have a workaround on this and it's to use --config-file nova_cell0.conf where we changed the connection string to use nova_cell0 instead of nova. This is still a bug in my opinion if customers have a big failure rate, that will consume a lot of disk space that could be avoided with the cleanup cronjobs.
Hi Team, Can I get an update with this as this impacting a very important customer?
Hey Chris, I created another BZ for another issue but this helps cleaning up common tables but some of them are not cleaned up which I feel like it's another issue. We do have a workaround which is to set the connection string to nova_cell0 instead of nova and call that configuration using nova-manage. Thank you very much, David Hill
Upstream patch has merged: https://review.opendev.org/507486
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:0283