Open Stack

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,
>