Archive Additional Command Args not applied to barman-cloud-check-wal-archive / barman-cloud-backup-list, breaking S3-compatible providers requiring virtual-hosted-style addressing

Environment:
- Barman Cloud plugin version: v0.14.0 (ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.14.0)
- barman-cloud Go module: v0.5.2-0.20260720143032-950b0f57e122
- Underlying barman-cloud-wal-archive binary version: 3.19.1
- CNPG operator version: 1.30.0 (ghcr.io/cloudnative-pg/cloudnative-pg:1.30.0)
- Object storage provider: Huawei Cloud OBS (S3-compatible, requires virtual-hosted-style addressing exclusively -- rejects path-style with 403 Forbidden on HeadBucket)

Summary:

spec.configuration.wal.archiveAdditionalCommandArgs on the ObjectStore CRD is documented as appending arguments to the barman-cloud-wal-archive invocation. In practice, it also needs to reach two other commands the plugin runs internally -- barman-cloud-check-wal-archive (the preflight check that gates the ContinuousArchiving cluster condition) and barman-cloud-backup-list (used by the retention/catalog-maintenance job) -- but it does not. This makes it impossible to configure --addressing-style virtual (or any other CLI flag) for providers that require it on all commands, not just the archive command itself.

Reproduction:

1. Configure an ObjectStore against an S3-compatible provider that requires virtual-hosted-style addressing (Huawei OBS in our case):

apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
name: huawei-obs
spec:
configuration:
destinationPath: "s3://my-bucket/"
endpointURL: "https://obs.me-east-1.myhuaweicloud.com"
s3Credentials:
accessKeyId: {name: my-secret, key: ACCESS_KEY_ID}
secretAccessKey: {name: my-secret, key: SECRET_ACCESS_KEY}
region: {name: my-secret, key: REGION}
wal:
archiveAdditionalCommandArgs:
- "--addressing-style"
- "virtual"

2. Confirm the flag reaches the intended command -- logs show it correctly applied when barman-cloud-wal-archive itself runs.

3. Observe the cluster's ContinuousArchiving condition remains False/ContinuousArchivingFailing. Sidecar logs show the check command running WITHOUT the flag:

"options":["--endpoint-url","https://obs.me-east-1.myhuaweicloud.com","--cloud-provider","aws-s3","s3://my-bucket/","pg-16"]

(no --addressing-style present), followed by:

ERROR: Barman cloud WAL archive check exception: An error occurred (403) when calling the HeadBucket operation: Forbidden

4. Similarly, barman-cloud-backup-list (retention job) fails with:

ERROR: Barman cloud backup list exception: An error occurred (VirtualHostDomainRequired) when calling the ListObjectsV2 operation: Virtual host domain is required while accessing a specific bucket.

Confirmed working when tested manually, outside the plugin:

aws s3api head-bucket --bucket my-bucket --endpoint-url https://obs.me-east-1.myhuaweicloud.com --region me-east-1

fails with 403 Forbidden using default (path-style) addressing, but succeeds cleanly after:

aws configure set default.s3.addressing_style virtual

using the identical IAM credentials, bucket, and endpoint -- confirming the credentials, IAM policy, and bucket policy are all correct, and the only variable is addressing style.

Expected behavior:

archiveAdditionalCommandArgs (or a new, explicitly-documented mechanism) should apply consistently to every barman-cloud-* invocation the plugin makes against a given ObjectStore -- including the WAL archive preflight check and the retention/catalog commands -- not just the archive command itself.

Workaround attempted (did not work):

Setting BARMAN_S3_USE_PATH_STYLE=false via instanceSidecarConfiguration.env -- confirmed present in the running sidecar's environment via kubectl exec, but had no effect on the 403, suggesting this env var is not read by the underlying Go/barman-cloud-* invocation path at all.

Context:

This is affecting a data-residency-driven use case (Saudi Arabia in-Kingdom storage requirement), where Huawei OBS is one of the few providers with a live regional presence today. Happy to provide additional logs or test further configuration changes if helpful.

Commencez par retracer comment archiveAdditionalCommandArgs est transmis à l’invocation de barman-cloud-wal-archive du plugin, puis suivez les points d’entrée internes barman-cloud-check-wal-archive et barman-cloud-backup-list. Vérifiez que les arguments parviennent à chaque commande et reproduisez l’échec lié au style d’adressage de Huawei OBS ; le travail est considéré comme terminé lorsque toutes les invocations pertinentes acceptent les arguments configurés sans modifier le comportement d’archivage existant.

Rédigé par le modèle d'indexation à partir du texte de l'issue.