Open Stack

Le 20/11/2015 17:36, Matt Riedemann a écrit :
>
>
> 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
>

Okay, that seems a good usecase for operators. Coolness, I'm fine with 
soft-deleting instance_actions and provide a microversion for getting 
actions for a known instance UUID, like Andrew said.