On 11/20/2015 11:36 AM, Matt Riedemann wrote: > > > 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-requ...@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-requ...@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
+1 I think we need that on a T-shirt -- Sean Dague http://dague.net __________________________________________________________________________ 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
