<font size=2 face="sans-serif">in ceilometer we have a bug regarding residual
dump tables left after migration: </font><a href="https://bugs.launchpad.net/ceilometer/+bug/1259724"><font size=2 color=blue face="sans-serif">https://bugs.launchpad.net/ceilometer/+bug/1259724</font></a>
<br>
<br><font size=2 face="sans-serif">basically, in a few prior migrations,
when adding missing constraints, a dump table was create to backup values
which didn't fit into the new constraints. i raised the initial bug because
i believe there is very little value to these tables as i would expect
any administrator capturing data of some importance would backup their
data before any migration to begin with.  i noticed in Nova, they
also clean up their dump tables but i wanted to raise this on mailing list
so that everyone is aware of the issue before i add a patch which blows
away these dump tables. :)</font>
<br>
<br><font size=2 face="sans-serif">i'd be interested if anyone actually
finds value in having these dump tables persist just so we can see if your
use case can be handle without the tables.</font>
<br>
<br><font size=2 face="sans-serif">for reference, the dump tables are created
in:</font>
<br><a href=https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/sqlalchemy/migrate_repo/versions/012_add_missing_foreign_keys.py><font size=2 color=blue face="sans-serif">https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/sqlalchemy/migrate_repo/versions/012_add_missing_foreign_keys.py</font></a>
<br><a href=https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/sqlalchemy/migrate_repo/versions/027_remove_alarm_fk_constraints.py><font size=2 color=blue face="sans-serif">https://github.com/openstack/ceilometer/blob/master/ceilometer/storage/sqlalchemy/migrate_repo/versions/027_remove_alarm_fk_constraints.py</font></a>
<br><font size=2 face="sans-serif"><br>
cheers,<br>
gordon chung<br>
openstack, ibm software standards</font>