[openstack-dev] [nova] Question about fixing missing soft deleted rows

Sylvain Bauza sbauza at redhat.com
Thu Sep 15 13:10:59 UTC 2016



Le 15/09/2016 14:21, Sean Dague a écrit :
> On 09/14/2016 09:21 PM, Matt Riedemann wrote:
>> I'm looking for other input on a question I have in this change:
>>
>> https://review.openstack.org/#/c/345191/4/nova/db/sqlalchemy/api.py
>>
>> We've had a few patches like this where we don't (soft) delete entries
>> related to an instance when that instance record is (soft) deleted.
>> These then cause the archive command to fail because of the referential
>> constraint.
>>
>> Then we go in and add a new entry in the instance_destroy method so we
>> start (soft) deleting *new* things, but we don't cleanup anything old.
>>
>> In the change above this is working around the fact we might have
>> lingering consoles entries for an instance that's being archived.
>>
>> One suggestion I made was adding a database migration that soft deletes
>> any console entries where the related instance is deleted (deleted !=
>> 0). Is that a bad idea? It's not a schema migration, it's data cleanup
>> so archive works. We could do the same thing with a nova-manage command,
>> but we don't know that someone has run it like they do with the DB
>> migrations.
>>
>> Another idea is doing it in the nova-manage db online_data_migrations
>> command which should be run on upgrade. If we landed something like that
>> in say Ocata, then we could remove the TODO in the archive code in Pike.
>>
>> Other thoughts?
> Is there a reason that archive doesn't go hunt for these references
> first and delete them? I kind of assumed it would handle all the cleanup
> logic itself, including this sort of integrity issue.

That's the alternative approach I was thinking in my email. Yeah, maybe 
reconciling the DB when archiving the rows seems the better approach 
instead of a periodic call for fixing that.


> The data migration would still take time, and a table lock, even though
> it's just deletes, so that feels like it should be avoided.

Well, that could be done thru cursors so that the lock is not really a 
problem, but by thinking about that, I tend to agree with you on the 
best approach which could be fixing the archive command.

-Sylvain


> 	-Sean
>




More information about the OpenStack-dev mailing list