Requesting ability to pass manager args to the plugin sidecar

Based on #497 , there is currently no way to set the log level declaratively. I'd like to propose/request a feature to solve this.

I think it can be addressed by adding a setting on the ObjectStore's instanceSidecarConfiguration. For example:

...
spec:
  instanceSidecarConfiguration:
    managerArgs:
      - "--log-level debug"

This would give users control to set the full set of CLI args:

➜  ~ docker run -it ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.5.0 --help
Usage:
  manager [command]

Available Commands:
  completion  Generate the autocompletion script for the specified shell
  healthcheck healthcheck commands
  help        Help about any command
  instance    Starts the Barman Cloud CNPG-I sidecar plugin
  operator    Starts the BarmanObjectStore reconciler and the Barman Cloud CNPG-i plugin
  restore     Starts the Barman Cloud CNPG-I sidecar plugin

Flags:
  -h, --help                              help for manager
      --log-destination string            where the log stream will be written
      --log-field-level string            JSON log field to report severity in (default: level)
      --log-field-timestamp string        JSON log field to report timestamp in (default: ts)
      --log-level string                  the desired log level, one of error, info, debug and trace (default "info")
      --zap-devel                         Development Mode defaults(encoder=consoleEncoder,logLevel=Debug,stackTraceLevel=Warn). Production Mode defaults(encoder=jsonEncoder,logLevel=Info,stackTraceLevel=Error)
      --zap-encoder encoder               Zap log encoding (one of 'json' or 'console')
      --zap-log-level level               Zap Level to configure the verbosity of logging. Can be one of 'debug', 'info', 'error', 'panic'or any integer value > 0 which corresponds to custom debug levels of increasing verbosity
      --zap-stacktrace-level level        Zap Level at and above which stacktraces are captured (one of 'info', 'error', 'panic').
      --zap-time-encoding time-encoding   Zap time encoding (one of 'epoch', 'millis', 'nano', 'iso8601', 'rfc3339' or 'rfc3339nano'). Defaults to 'epoch'.

Use "manager [command] --help" for more information about a command.

It also seems consistent with the existing archiveAdditionalCommandArgs and restoreAdditionalCommandArgs on the WalBackupConfiguration and the additionalCommandArgs on the DataBackupConfiguration

Would using the Env field help with that?

// InstanceSidecarConfiguration defines the configuration for the sidecar that runs in the instance pods.
type InstanceSidecarConfiguration struct {
	// The environment to be explicitly passed to the sidecar
	// +optional
	Env []corev1.EnvVar `json:"env,omitempty"`

	// The retentionCheckInterval defines the frequency at which the
	// system checks and enforces retention policies.
	// +kubebuilder:default:=1800
	// +optional
	RetentionPolicyIntervalSeconds int `json:"retentionPolicyIntervalSeconds,omitempty"`

	// Resources define cpu/memory requests and limits for the sidecar that runs in the instance pods.
	// +optional
	Resources corev1.ResourceRequirements `json:"resources,omitempty"`
}

Using the env vars is not sufficient on its own. They don't get passed through to any of the CLI flags.

Here's one option as a temporary workaround:

Build your own plugin image. The Dockerfile is basically:

# Start from the original distroless sidecar image, which is built here:
# https://github.com/cloudnative-pg/plugin-barman-cloud/blob/main/containers/Dockerfile.sidecar
FROM ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.5.0 AS distroless
# Copy the necessary files from the distroless image into a debian-based Python image.
# This gives us a shell to run the wrapper entrypoint script.
FROM python:3.13.7-bookworm
COPY --from=distroless /usr /usr
COPY --from=distroless /manager /manager
# Pull in the wrapper script.
COPY manager-wrapper.sh /manager-wrapper.sh
# User and Entrypoint are copied from the original sidecar image, except we pass through the log level.
USER 26:26
# We need a wrapper script because ENTRYPOINT doesn't expand the environment variables that we use to pass through arguments.
ENTRYPOINT ["/manager-wrapper.sh"]

The manager-wrapper script is:

#!/bin/bash
set -e
# Using exec to ensure that manager is PID 1 and cleanly handles interrupts.
exec /manager --log-level ${LOG_LEVEL:-info} "$@"

Deploy the barman-cloud-plugin operator deployment with env var SIDECAR_IMAGE=your-custom-docker-image. This is what dictates the image used for the sidecar on each instance.
Deploy the object store with env var LOG_LEVEL=debug.
Restart the clusters to make them pick up the new sidecar image.

what you have described is correct, we don't set the env as defaults inside the addflags func

// AddFlags binds manager configuration flags to a given flagset
func (l *Flags) AddFlags(flags *pflag.FlagSet) {
	loggingFlagSet := &flag.FlagSet{}
	loggingFlagSet.StringVar(&logLevel, "log-level", "info",
		"the desired log level, one of error, info, debug and trace")
	loggingFlagSet.StringVar(&logDestination, "log-destination", "",
		"where the log stream will be written")
	loggingFlagSet.StringVar(&logfieldsRemap.LevelKey, "log-field-level", "",
		"JSON log field to report severity in (default: level)")
	loggingFlagSet.StringVar(&logfieldsRemap.TimeKey, "log-field-timestamp", "",
		"JSON log field to report timestamp in (default: ts)")
	l.zapOptions.BindFlags(loggingFlagSet)
	flags.AddGoFlagSet(loggingFlagSet)
}

Opened #520

feat(spec): add support for additional sidecar container arguments (c…

Navigation Menu

Repository navigation

Requesting ability to pass manager args to the plugin sidecar #501

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Requesting ability to pass manager args to the plugin sidecar #501

Description

Activity

armru commented on Sep 9, 2025

alexklibisz commented on Sep 9, 2025

alexklibisz commented on Sep 9, 2025

armru commented on Sep 15, 2025

armru commented on Sep 15, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions