Open Stack

Le 15/09/2016 03:21, Matt Riedemann a écrit :
> 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?
>

The real problem I see with a nova-manage db online_data_migrations or a 
database migration is that we are not fixing the root problem, which is 
that anytime someone is soft-deleting an instance, we're not also (soft 
or hard) deleting the related entries.

If we were providing that script, it would be needed to call it 
idempotentically, right?
If so, MHO is that a single nova-manage command (or subcommand) could be 
enough, using a marker and a limit.

The other alternative I could see is that the archive command would be 
healing the DB by deleting the entries that should have been 
(soft/hard)deleted if the related instance is soft-deleted too.

-Sylvain