[libvirt] [PATCH v2] logging: ensure virtlogd rollover takes priority over logrotate

[Jim Fehlig]

On 7/10/19 11:14 AM, Daniel P. Berrangé  wrote:
> The virtlogd config is set to rollover logs every 2 MB.
> 
> Normally a logrotate config file is also installed to handle cases where
> virtlogd is disabled. This is set to rollover weekly with no size
> constraint.
> 
> As a result logrotate can interfere with virtlogd's, rolling over files
> that virtlogd has already taken care of.
> 
> This changes logrotate configs to rollover based on a max size
> constraint of 2 MB + 1 byte. When virtlogd is running the log files will
> never get this large, making logrotate a no-op.
> 
> If the user changes the size in virtlogd's config to something larger,
> they are responsible for also changing the logrotate config suitably.
> 
> The LXC driver doesn't use virtlogd, but its logrotate config is altered
> to match the QEMU driver logrotate, just for the sake of consistency.
> 
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>   src/logging/virtlogd.conf              |  6 ++++++
>   src/remote/libvirtd.libxl.logrotate.in |  2 +-
>   src/remote/libvirtd.lxc.logrotate.in   |  2 +-
>   src/remote/libvirtd.qemu.logrotate.in  | 10 +++++++++-
>   4 files changed, 17 insertions(+), 3 deletions(-)

This patch looks good based on requirement of logrotate not interfering with 
virtlogd rotation, and for that

Reviewed-by: Jim Fehlig <jfehlig at suse.com>

But the problem of unpurged log files that Jan was attempting to solve remains. 
If I understood your response to to his V2 patch [0], virtlogd needs to gain 
support for purging log files for old transient VMs after some configurable time?

In the private bug (sorry) that initiated this discussion I suggested adjusting 
the logrotate config via cloud deployment tool, pushing rotation policy 
decisions off to the "admin". What is your opinion on fixing this in upstream 
libvirt vs configuration at deployment?

Regards,
Jim

[0] https://www.redhat.com/archives/libvir-list/2019-July/msg00368.html