Open Stack

On Wed, 2021-02-10 at 12:37 +0100, Belmiro Moreira wrote:
> 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).

thanks that is useful.
that is what i was expecting to be a good defualt setup
keep for 30 days but run daily with no row limit.
that way you are archiving/deleteing 1 days worth of entries every day but keeping them for 30 days before they are removed.

> 
> Belmiro
> 
> 
> On Fri, Jan 29, 2021 at 3:28 PM Sean Mooney <smooney at 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,
> > > 
> > 
> > 
> > 
> >