Open Stack

On 10/30/2014 03:30 PM, Abel Lopez wrote:
> It seems that every release, there is more and more emphasis on upgradability. This is a good thing, I've love to see production users easily go from old to new.
>
> As an operator, I've seen first hand the results of neglecting the databases that openstack creates. If we intend to have users go year-over-year with upgrades, we're going to expect them to carry huge databases around.
>
> Just in my lab, I have over 100000 deleted instances in the last two months.
> Frankly, I'm not convinced that simply archiving deleted rows is the best idea. Sure, gets your production databases and tables to a manageable size, but you're simply hoarding old data.
>
> As an operator, I'd prefer to have time based criteria over number of rows, too.
> I envision something like `nova-manage db purge [days]` where we can leave it up to the administrator to decide how much of their old data (if any) they'd be OK losing.
>
> Think about data destruction guidelines too, some companies require old data be destroyed when not needed, others require maintaining it.
> We can easily provide both here.
>
> I've drafted a simple blueprint https://blueprints.launchpad.net/nova/+spec/database-purge
>
> I've love some input from the community.
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
HP's LBaaS code (libra), uses something similar for the reasons you 
state - 
http://libra.readthedocs.org/en/latest/admin_api/schedulers.html#expunge-scheduler

The admin-api code would go through and wipe any records that were older 
than the --expire-days parameter, although this was more of an automated 
process vs. a user-triggered function.

++ on the notion that this would be a useful and integrated 
quality-of-life tool for operations. Am in favor.