Open Stack

On 12/12/2014 08:54 PM, melanie witt wrote:
> Hi everybody,
>
> At some point, our db archiving functionality got broken because there was a change to stop ever deleting instance system metadata [1]. For those unfamiliar, the 'nova-manage db archive_deleted_rows' is the thing that moves all soft-deleted (deleted=nonzero) rows to the shadow tables. This is a periodic cleaning that operators can do to maintain performance (as things can get sluggish when deleted=nonzero rows accumulate).
>
> The change was made because instance_type data still needed to be read even after instances had been deleted, because we allow admin to view deleted instances. I saw a bug [2] and two patches [3][4] which aimed to fix this by changing back to soft-deleting instance sysmeta when instances are deleted, and instead allow read_deleted="yes" for the things that need to read instance_type for deleted instances present in the db.
>
> My question is, is this approach okay? If so, I'd like to see these patches revive so we can have our db archiving working again. :) I think there's likely something I'm missing about the approach, so I'm hoping people who know more about instance sysmeta than I do, can chime in on how/if we can fix this for db archiving. Thanks.

I looked briefly into tackling this as well a while back.  The tricky 
piece that I hit is what system_metadata should be available when 
read_deleted='yes'.  Is it okay for it to be all deleted system_metadata 
or should it only be the system_metadata that was deleted at the same 
time as the instance?  I didn't get to dig in enough to answer that.

Also there are periodic tasks that query for deleted instances so those 
might need to pull system_metadata in addition to the API.


>
> [1] https://bugs.launchpad.net/nova/+bug/1185190
> [2] https://bugs.launchpad.net/nova/+bug/1226049
> [3] https://review.openstack.org/#/c/110875/
> [4] https://review.openstack.org/#/c/109201/
>
> melanie (melwitt)
>
>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141216/4cb7b21b/attachment.html>