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@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
