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