Resizer doesnt support log to the file using klog methods

[parth-gr]

External-resizer uses the klog for it's logging mechanism. Klog provides various methods to be used, including logging into the file by setting the flag, flag.Set("log_file", "var/a5.log").

But using the flag looks like it throughs error,

PS: Using it with ceph-csi pod container, rook/rook#14305

[rider@localhost examples]$ kubectl logs csi-rbdplugin-provisioner-66bcf974b8-gbjxx -c csi-resizer -nrook-ceph
flag provided but not defined: -log_file
Usage of /csi-resizer:
  -csi-address string
    	Address of the CSI driver socket. (default "/run/csi/socket")
  -feature-gates value
    	A set of key=value paris that describe feature gates for alpha/experimental features for csi external resizer.Options are:
    	AllAlpha=true|false (ALPHA - default=false)
    	AllBeta=true|false (BETA - default=false)
    	AnnotateFsResize=true|false (ALPHA - default=false)
    	RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
    	VolumeAttributesClass=true|false (ALPHA - default=false)
  -handle-volume-inuse-error
    	Flag to turn on/off capability to handle volume in use error in resizer controller. Defaults to true if not set. (default true)
  -http-endpoint :8080
    	The TCP network address where the HTTP server for diagnostics, including metrics and leader election health check, will listen (example: :8080). The default is empty string, which means the server is disabled. Only one of `--metrics-address` and `--http-endpoint` can be set.
  -kube-api-burst int
    	Burst to use while communicating with the kubernetes apiserver. Defaults to 10. (default 10)
  -kube-api-qps float
    	QPS to use while communicating with the kubernetes apiserver. Defaults to 5.0. (default 5)
  -kubeconfig string
    	Absolute path to the kubeconfig
  -leader-election
    	Enable leader election.
  -leader-election-lease-duration duration
    	Duration, in seconds, that non-leader candidates will wait to force acquire leadership. Defaults to 15 seconds. (default 15s)
  -leader-election-namespace string
    	Namespace where the leader election resource lives. Defaults to the pod namespace if not set.
  -leader-election-renew-deadline duration
    	Duration, in seconds, that the acting leader will retry refreshing leadership before giving up. Defaults to 10 seconds. (default 10s)
  -leader-election-retry-period duration
    	Duration, in seconds, the LeaderElector clients should wait between tries of actions. Defaults to 5 seconds. (default 5s)
  -log-flush-frequency duration
    	Maximum number of seconds between log flushes (default 5s)
  -log-json-info-buffer-size value
    	[Alpha] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). Enable the LoggingAlphaOptions feature gate to use this.
  -log-json-split-stream
    	[Alpha] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. Enable the LoggingAlphaOptions feature gate to use this.
  -logging-format string
    	Sets the log format. Permitted formats: "json" (gated by LoggingBetaOptions), "text". (default "text")
  -master string
    	Master URL to build a client config from. Either this or kubeconfig needs to be set if the provisioner is being run out of cluster.
  -metrics-address :8080
    	(deprecated) The TCP network address where the prometheus metrics endpoint will listen (example: :8080). The default is empty string, which means metrics endpoint is disabled. Only one of `--metrics-address` and `--http-endpoint` can be set.
  -metrics-path /metrics
    	The HTTP path where prometheus metrics will be exposed. Default is /metrics. (default "/metrics")
  -resync-period duration
    	Resync period for cache (default 10m0s)
  -retry-interval-max duration
    	Maximum retry interval of failed volume resize. (default 5m0s)
  -retry-interval-start duration
    	Initial retry interval of failed volume resize. It exponentially increases with each failure, up to retry-interval-max. (default 1s)
  -timeout duration
    	Timeout for waiting for CSI driver socket. (default 10s)
  -v value
    	number for the log level verbosity
  -version
    	Show version
  -vmodule value
    	comma-separated list of pattern=N settings for file-filtered logging (only works for text log format)
  -workers int
    	Concurrency to process multiple resize requests (default 10)

I suspect it is because
klog.InitFlags(nil) and klog.Flush() isn't called, but there can be some other bug too at the same time

[Madhu-1]

cc @gnufied

[parth-gr]

@Madhu-1 @gnufied we need to use the klog.InitFlags(nil) with the main function to bring back the klog flags,

But the problem is klog and k8s.io/component-base/logs has a common defined flag v, so if we try to initialize both the libraries flag at the same time, We get error from Go,

Existing -v flag found, removing it.
/csi-resizer flag redefined: v
panic: /csi-resizer flag redefined: v

And according to mine findings we cannot re-define any flag, so any suggestion for this.

And the last way is to revert the k8s.io/component-base/logs #330 and just use the klogs

cc @saku3 any suggestions?

[parth-gr]

Or we should ask here to support editing of flag values https://github.com/golang/go/blob/master/src/flag/flag.go#L1010

[gnufied]

The flags of klog are being deprecated as per accepted KEP - https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components

What is the use case ? Why you want to log to a file? cc @pohly

[parth-gr]

What is the use case ? Why you want to log to a file?

@gnufied we need to persist the log for the pod containers, and also support log rotation specific to the pod, so for that we need to create a log file, which is govern by klog.

[Madhu-1]

@gnufied all other sidecars have klog and only it's not present in the resizer, For now sidecars are not consistent with this functionality, if we are moving away from klog

1. Do we have a similar functionality to write a log to a file or do we need to have some other custom mechanism to write to a log as mentioned in the KEP
2. Are we planning to update all the sidecars to move away from klog, If yes, when it is planned?

Based on these the users can plan accordingly

[gnufied]

Are we planning to update all the sidecars to move away from klog, If yes, when it is planned?

Technically, we are not moving away from klog, but we are are going to be adopting kubernetes/enhancements#2845. So I suspect - -log_file option is going away from other sidecars too, sooner or later. So it might be better to design around non-availability of that option.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.