cloudnative-pg / cloudnative-pg/plugin-barman-cloud

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

Abierto
#1,091 5 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Go
Estrellas
191
Forks
72
Merge medio
1 d 16 h
PR fusionados (30 d)
18

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Comienza siguiendo cómo se pasa archiveAdditionalCommandArgs a la invocación de barman-cloud-wal-archive del plugin y, después, sigue los puntos de entrada internos barman-cloud-check-wal-archive y barman-cloud-backup-list. Verifica que los argumentos lleguen a cada comando y reproduce el fallo del estilo de direccionamiento de Huawei OBS; se considera terminado cuando todas las invocaciones relevantes acepten los argumentos configurados sin romper el comportamiento de archivado existente.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
aws, go
Área
backend, cloud
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Activo
Claridad
Bastante claro
Aptitud para principiantes
52/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.