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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
