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-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
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.
__________________________________________________________________________
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
