Hi, at CERN, Nova shadow tables are used to keep the deleted entries for 30 days. We have a cronjob, that runs every day, to move the deleted rows into the shadow tables and purge them using nova-manage (deleted rows are kept in the shadow tables for 30 days).
For other projects that keep deleted rows but don't have shadow tables, for example Glance, we purge the tables everyday with glance-manage (again, keeping the deleted rows for 30 days).
Belmiro
On Fri, Jan 29, 2021 at 3:28 PM Sean Mooney smooney@redhat.com wrote:
On Fri, 2021-01-29 at 13:47 +0100, Thierry Carrez wrote:
Arnaud Morin wrote:
[...] We were wondering if some other users would be interested in using the tool, and maybe move it under the opendev governance?
Resurrecting this thread, as OSops has now been revived under the auspices of the OpenStack Operation Docs and Tooling SIG.
There are basically 3 potential ways forward for OSarchiver:
1- Keep it as-is on GitHub, and reference it where we can in OpenStack
docs
2- Relicense it under Apache-2 and move it in a subdirectory under openstack/osops
3- Move it under its own repository under opendev and propose it as a new official OpenStack project (relicensing under Apache-2 will be necessary if accepted)
Options (1) and (3) have the benefit of keeping it under its own repository. Options (2) and (3) have the benefit of counting towards an official OpenStack contribution. Options (1) and (2) have the benefit of not requiring TC approval.
All other things being equal, if the end goal is to increase discoverability, option 3 is probably the best.
not to detract form the converation on where to host it, but now that i have discoverd this via this thread i have one quetion. OSarchiver appears to be bypassing the shadow tabels whcih the project maintian to allow you to archive rows in the the project db in a different table.
instad OSarchiver chooese to archive it in an external DB or file
we have talked about wheter or not we can remove shaddow tables in nova enteirly a few times in the past but we did not want to break operators that actully use them but it appares OVH at least has developed there own alrenitive presumably becasue the proejcts own archive and purge functionality was not meetingyour need.
would the option to disable shadow tabels or define a retention policy for delete rows be useful to operators or is this even a capablity that project coudl declare out of scope and delegate that to a new openstack porject e.g. opeiton 3 above to do instead?
im not sure how suportable OSarchiver would be in our downstream product right now but with testing it might be somethign we could look at includign in the futrue. we currently rely on chron jobs to invoke nova-magne ecta to achive similar functionality to OSarchiver but if that chron job breaks its hard to detect and the delete rows can build up causing really slow db queries. as a seperate service with loggin i assuem this is simplere to monitor and alarm on if it fails since it provices one central point to manage the archival and deletion of rows so i kind of like this approch even if its direct db access right now would make it unsupportable in our product without veting the code and productising the repo via ooo integration.
Regards,