Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,091 5 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
aws, go
Ambito
backend, cloud

Direzione di ricerca

Inizia tracciando come archiveAdditionalCommandArgs viene passato all’invocazione di barman-cloud-wal-archive del plugin, quindi segui gli entry point interni barman-cloud-check-wal-archive e barman-cloud-backup-list. Verifica che gli argomenti raggiungano ogni comando e riproduci il problema dello stile di indirizzamento di Huawei OBS; il lavoro è completato quando tutte le invocazioni pertinenti accettano gli argomenti configurati senza compromettere il comportamento di archiviazione esistente.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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"

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

  2. 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

  1. 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.

Lingua principale
Go
Stelle
198
Fork
81
Merge medio
2g 6h
PR unite (30g)
19

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cloudnative-pg/plugin-barman-cloud

Tutte le issue di cloudnative-pg/plugin-barman-cloud

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.