[ops] database archiving tool
Pierre-Samuel LE STANG
pierre-samuel.le-stang at corp.ovh.com
Wed May 22 11:49:02 UTC 2019
Thomas Goirand <zigo at debian.org> wrote on mer. [2019-mai-22 13:24:19 +0200]:
> On 5/22/19 10:34 AM, Pierre-Samuel LE STANG wrote:
> > Thomas Goirand <zigo at debian.org> wrote on mer. [2019-mai-22 09:09:25 +0200]:
> >> Hi Pierre,
> >> That's really the kind of project that I would prefer not to have to
> >> exist. By this I mean, it'd be a lot nicer if this could be taken care
> >> of project by project, with something like what Nova does (ie:
> >> nova-manage db archive_deleted_rows).
> >> In such configuration, that's typically something that could be added as
> >> a cron job, automatically configured by packages.
> >> Now, a question for other OPS reading this thread: how long should be
> >> the retention? In Debian, we use to have the unsaid policy that we don't
> >> want too much retention, to project privacy. Though in operation, we may
> >> need at least a few weeks of history, so we can do support. If I was to
> >> configure a cron job for nova, for example, what parameter should I set
> >> to --before (when #556751 is merged)? My instinct would be:
> >> nova-manage db archive_deleted_rows \
> >> --before $(date -d "-1 month" +%Y-%m-%d)
> >> Your thoughts everyone?
> > Hi Thomas,
> > Thanks for your feedback, I really appreciate it. The tool is designed to be
> > customized and to fit your needs. It means that you can have one configuration
> > per project or one configuration for all projects.
> > So you might imagine having a configuration for glance which exclude images
> > table and one configuration for nova with a higher or lower retention.
> > --
> > PS
> This looks super nice then!
> Will you provide a standard configuration for every OpenStack project?
> It'd be nice if your package had a conf.d folder where one could drop
> the config for every project. That way, every OpenStack project package
> could drop a configuration there.
> Thomas Goirand (zigo)
I will provide a default configuration file that might be used as a template or
I did not consider adding the conf.d folder mechanism as all the different
configurations can be written in the same config file but that sounds good to
make the things clearer an easier.
I'm still focus on making the code opensource as soon as it's done we will be
able to make the tool evolve.
More information about the openstack-discuss