[openstack-dev] [nova] nova-manage db archive_deleted_rows broken

Matt Riedemann mriedem at linux.vnet.ibm.com
Fri Nov 20 16:36:39 UTC 2015



On 11/20/2015 10:04 AM, Andrew Laski wrote:
> On 11/20/15 at 09:51am, Matt Riedemann wrote:
>>
>>
>> On 11/20/2015 8:18 AM, Sean Dague wrote:
>>> On 11/17/2015 10:51 PM, Matt Riedemann wrote:
>>> <snip>
>>>>
>>>> I *don't* see any DB APIs for deleting instance actions.
>>>>
>>>> Kind of an important difference there.  Jay got it at least. :)
>>>>
>>>>>
>>>>> Were we just planning on instance_actions living forever in the
>>>>> database?
>>>>>
>>>>> Should we soft delete instance_actions when we delete the referenced
>>>>> instance?
>>>>>
>>>>> Or should we (hard) delete instance_actions when we archive (move to
>>>>> shadow tables) soft deleted instances?
>>>>>
>>>>> This is going to be a blocker to getting nova-manage db
>>>>> archive_deleted_rows working.
>>>>>
>>>>> [1] https://review.openstack.org/#/c/246635/
>>>
>>> instance_actions seems extremely useful, and at the ops meetups I've
>>> been to has been one of the favorite features because it allows and easy
>>> interface for "going back in time" to figure out what happened.
>>>
>>> I'd suggest the following:
>>>
>>> 1. soft deleting and instance does nothing with instance actions.
>>>
>>> 2. archiving instance (soft delete -> actually deleted) also archives
>>> off instance actions.
>>
>> I think this is also the right approach. Then we don't need to worry
>> about adding soft delete for instance_actions, they are just archived
>> when you archive the instances. It probably makes the logic in the
>> archive code messier for this separate path, but it's looking like
>> we're going to have to account for the bw_usage_cache table too (which
>> has a uuid column for an instance but no foreign key back to the
>> instances table and is not soft deleted).
>>
>>>
>>> 3. update instance_actions API so that you can get instance_actions for
>>> deleted instances (which I think doesn't work today).
>>
>> Right, it doesn't. I was going to propose a spec for that since it's a
>> simple API change with a microversion.
>
> Adding a simple flag to expose instance actions for a deleted instance
> if you know the uuid of the deleted instance will provide some
> usefulness.  It does lack the discoverability of knowing that you had
> *some* instance that was deleted and you don't have the uuid but want to
> get at the deleted actions.  I would like to avoid bolting that onto
> instance actions and keep that as a use case for an eventual Task API.
>
>>
>>>
>>>     -Sean
>>>
>>
>> --
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>> __________________________________________________________________________
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

If you're an admin, you can list deleted instances using:

nova list --deleted

Or could, if we weren't busted on that right now [1].

So the use case I'm thinking of here is:

1. Multiple users are in the same project/tenant.
2. User A deletes an instance.
3. User B is wondering where the instance went, so they open a support 
ticket.
4. The admin checks for deleted instances on that project, finds the one 
in question.
5. Calls off to os-instance-actions with that instance uuid to see the 
deleted action and the user that did it (user A).
6. Closes the ticket saying that user A deleted the instance.
7. User B punches user A in the gut.

[1] https://bugs.launchpad.net/nova/+bug/1518382

-- 

Thanks,

Matt Riedemann




More information about the OpenStack-dev mailing list