Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

component-base: move v/vmodule/log-flush-frequency into LoggingConfiguration #106090

Merged
merged 3 commits into from Nov 4, 2021
Merged

component-base: move v/vmodule/log-flush-frequency into LoggingConfiguration #106090

merged 3 commits into from Nov 4, 2021

Commits on Nov 3, 2021

  1. component-base: move v/vmodule/log-flush-frequency into LoggingConfig… 

    …uration

These three options are the ones from logs.AddFlags which are not deprecated.
Therefore it makes sense to make them available also via the configuration file
support in the one command which currently supports that (kubelet).

Long-term, all commands should use LoggingConfiguration, either with a
configuration file (as in kubelet) or via flags (kube-scheduler,
kube-apiserver, kube-controller-manager).

Short-term, both approaches have to be supported. As the majority of the
commands only use logs.AddFlags, that function by default continues to register
the flags and only leaves that to Options.AddFlags when explicitly requested.

A drive-by bug fix is done for log flushing: the periodic flushing called
klog.Flush and therefore missed explicit flushing of the newer logr
backend. This bug was never present in any release Kubernetes and therefore the
fix is not submitted in a separate PR.
    @pohly
    pohly committed Nov 3, 2021
    Configuration menu
    Copy the full SHA
    3948cb8 View commit details
    Browse the repository at this point in the history

  2. component-base: initialize logging as soon as possible 

    In various places log messages where emitted as part of validation or even
before it (for example, cli.PrintFlags). Those log messages did not use the
final logging configuration, for example text output instead of JSON or not the
final verbosity. The last point became more obvious after moving the setup of
verbosity into logs.Options.Apply because PrintFlags never printed anything
anymore.

In order to force applications to deal with logging as soon as possible, the
Options.Validate and Options.Apply methods are now private. Applications should
use the new Options.ValidateAndApply directly after parsing.
    @pohly
    pohly committed Nov 3, 2021
    Configuration menu
    Copy the full SHA
    4df70df View commit details
    Browse the repository at this point in the history

  3. kubelet: avoid deprecation remark for traditional logging flags 

    Just because the options can now also be set via a configuration file does not
mean that the command line flags should not be used anymore.
    @pohly
    pohly committed Nov 3, 2021
    Configuration menu
    Copy the full SHA
    2590703 View commit details
    Browse the repository at this point in the history