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

[HussainBarakat]

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.

[dosubot]

Hi @HussainBarakat! I'm Dosu and I'm helping the CloudNativePG team.

Your analysis checks out against the code. archiveAdditionalCommandArgs and restoreAdditionalCommandArgs are only ever consumed by AppendArchiveAdditionalCommandArgs / AppendRestoreAdditionalCommandArgs, which are wired into BarmanCloudWalArchiveOptions (for barman-cloud-wal-archive) and CloudWalRestoreOptions (for barman-cloud-wal-restore) respectively [1] [2].

The two commands you flagged build their option lists independently, with no additional-args hook at all:

• barman-cloud-check-wal-archive — BarmanCloudCheckWalArchiveOptions only appends --endpoint-url, cloud-provider flags, destination path, and server name. CheckBackupDestination calls it directly with no extra-args plumbing.
• barman-cloud-backup-list — executeQueryCommand likewise only appends --format json, endpoint URL, cloud-provider flags, destination path, and server name.
• barman-cloud-backup-delete — DeleteBackupsByPolicy follows the same pattern: no additional-args mechanism.

So this isn't limited to your case — archiveAdditionalCommandArgs / restoreAdditionalCommandArgs were only plumbed into the two commands whose names match (archive / restore), and the check, list, and delete commands were left out entirely. This matches a related open request where another user needs deleteAdditionalCommandArgs to pass --batch-size for NetApp ONTAP.

A fix would need to add equivalent additional-args wiring (and likely new CRD fields or a single shared "global additional args" field) to BarmanCloudCheckWalArchiveOptions, executeQueryCommand, and DeleteBackupsByPolicy in the barman-cloud module, then thread them through from the plugin side.

Want me to dig further into how a fix might be structured — for example whether a single shared field applied to every barman-cloud invocation would be simpler than per-command fields?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[HussainBarakat]

@dosu Thanks for digging into this and confirming it lines up with the actual code — appreciate the thorough look. Yeah, would definitely be interested in seeing how a fix might come together. Since #1049 is basically asking for the same thing but for a different command, feels like a single shared field that applies to every barman-cloud invocation would make more sense than adding a new one-off field each time someone hits this. Would save you from doing this again for the next command down the line too. Happy to test whatever you come up with against my Huawei OBS setup once it's ready — I've already got everything set up to reproduce this pretty reliably at this point.

…

On Tue, Sep 1, 2026 at 11:21 AM dosubot[bot] ***@***.***> wrote: *dosubot[bot]* left a comment (cloudnative-pg/plugin-barman-cloud#1091) <#1091 (comment)> Hi @HussainBarakat <https://github.com/HussainBarakat>! I'm Dosu <https://go.dosu.dev/dosubot> and I'm helping the CloudNativePG team. Your analysis checks out against the code. archiveAdditionalCommandArgs and restoreAdditionalCommandArgs are only ever consumed by AppendArchiveAdditionalCommandArgs / AppendRestoreAdditionalCommandArgs, which are wired into BarmanCloudWalArchiveOptions (for barman-cloud-wal-archive) and CloudWalRestoreOptions (for barman-cloud-wal-restore) respectively [1] <https://grep.app/api/search?q=AppendArchiveAdditionalCommandArgs&filter%5Brepo%5D%5B0%5D=cloudnative-pg/barman-cloud> [2] <https://raw.githubusercontent.com/cloudnative-pg/barman-cloud/main/pkg/command/commandbuilder.go> . The two commands you flagged build their option lists independently, with no additional-args hook at all: - *barman-cloud-check-wal-archive* — BarmanCloudCheckWalArchiveOptions <https://github.com/cloudnative-pg/barman-cloud/blob/main/pkg/archiver/archiver.go?plain=1> only appends --endpoint-url, cloud-provider flags, destination path, and server name. CheckBackupDestination <https://github.com/cloudnative-pg/plugin-barman-cloud/blob/3958ee480531f08cfab3958a759186dd7f90480d/internal/cnpgi/common/check.go> calls it directly with no extra-args plumbing. - *barman-cloud-backup-list* — executeQueryCommand <https://raw.githubusercontent.com/cloudnative-pg/barman-cloud/main/pkg/command/backuplist.go> likewise only appends --format json, endpoint URL, cloud-provider flags, destination path, and server name. - *barman-cloud-backup-delete* — DeleteBackupsByPolicy <https://raw.githubusercontent.com/cloudnative-pg/barman-cloud/main/pkg/command/backupdelete.go> follows the same pattern: no additional-args mechanism. So this isn't limited to your case — archiveAdditionalCommandArgs / restoreAdditionalCommandArgs were only plumbed into the two commands whose names match (archive / restore), and the check, list, and delete commands were left out entirely. This matches a related open request <#1049> where another user needs deleteAdditionalCommandArgs to pass --batch-size for NetApp ONTAP. A fix would need to add equivalent additional-args wiring (and likely new CRD fields or a single shared "global additional args" field) to BarmanCloudCheckWalArchiveOptions, executeQueryCommand, and DeleteBackupsByPolicy in the barman-cloud module, then thread them through from the plugin side. Want me to dig further into how a fix might be structured — for example whether a single shared field applied to every barman-cloud invocation would be simpler than per-command fields? *To reply, just mention @dosu <https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=cloudnative-pg%2Fplugin-barman-cloud>.* ------------------------------ Docs are dead. Just use Dosu <https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-tagline&utm_term=cloudnative-pg%2Fplugin-barman-cloud> . [image: Leave Feedback] <https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-feedback&utm_term=cloudnative-pg%2Fplugin-barman-cloud&message_id=3027cc8d-00d0-431c-951a-7b97f91ae6cb> [image: Ask Dosu about plugin-barman-cloud] <https://github.dosu.com/cloudnative-pg/plugin-barman-cloud?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-ask-repo&utm_term=cloudnative-pg%2Fplugin-barman-cloud> [image: Share Dosu with your team] <https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=static-docs-share-team&utm_term=cloudnative-pg%2Fplugin-barman-cloud> — Reply to this email directly, view it on GitHub <#1091?email_source=notifications&email_token=AUYBZJ3SC55UFZOHCB6HUEL5M2BIXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGEYDOMBUHA32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5491070487>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUYBZJZWSX4VTOX2FPDHUZT5M2BIXAVCNFSNUABFKJSXA33TNF2G64TZHM4DMMRTGQ2DAMZTHNEXG43VMU5TKMZQHE2DONJRGQ22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AUYBZJZXCF6XMQGH3XQSM4T5M2BIXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGEYDOMBUHA32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AUYBZJ6BKOLEGPERBMAIZX35M2BIXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGEYDOMBUHA32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosubot]

@HussainBarakat glad to hear you're ready to test — that'll be valuable.

On the design direction: the project has already committed to the per-command-field pattern rather than a single global field. There's an open (unmerged) PR pair that covers two of the remaining gaps:

• cloudnative-pg/barman-cloud#249 adds ShowAdditionalCommandArgs and ListAdditionalCommandArgs to DataBackupConfiguration, along with Append* helpers wired into GetBackupList / GetBackupByName via executeQueryCommand.
• cloudnative-pg/plugin-barman-cloud#924 is the sister PR that exposes those as new CRD fields (showAdditionalCommandArgs, listAdditionalCommandArgs) under spec.configuration.data. It depends on chore(deps): update all sagikazarmark daggerverse dependencies to e6c1417 #249 merging first and a barman-cloud release being cut.

This extends the existing set of per-command fields — data.additionalCommandArgs, wal.archiveAdditionalCommandArgs, wal.restoreAdditionalCommandArgs, and data.restoreAdditionalCommandArgs [1] — rather than replacing them with a single shared field.

That said, your two specific pain points — barman-cloud-check-wal-archive and barman-cloud-backup-delete — still don't have PRs. CheckBackupDestination calls BarmanCloudCheckWalArchiveOptions directly with no additional-args plumbing [2], and DeleteBackupsByPolicy has the same gap (which is also what #1049 needs for --batch-size on NetApp ONTAP). There is precedent for extending BarmanCloudCheckWalArchiveOptions — it recently gained a WithTimeline functional option in barman-cloud#212 — so adding a checkAdditionalCommandArgs / deleteAdditionalCommandArgs would follow the same shape.

Once #249/#924 ship, the listAdditionalCommandArgs field should at least fix your barman-cloud-backup-list failures (retention pruning). The barman-cloud-check-wal-archive preflight check would still need its own field.

I don't have visibility into a timeline for #249/#924 merging — neither PR has maintainer review comments yet. But they're the ones to watch for your use case.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[HussainBarakat]

Thanks for digging up the PR links — really useful to see the actual direction. Good to know #249/#924 will fix the list/retention side. But just to flag clearly: my actual blocker isn't the retention pruning, it's barman-cloud-check-wal-archive — that's the one gating the ContinuousArchiving status itself, so even with #249/#924 merged I'd still be stuck unable to use Huawei OBS at all. Given you mentioned there's precedent for extending BarmanCloudCheckWalArchiveOptions (the WithTimeline addition), would it be worth filing a companion PR for checkAdditionalCommandArgs following that same shape? Happy to test against my setup the moment something's up, if that helps move it along.

…

On Tue, Sep 1, 2026 at 2:18 PM dosubot[bot] ***@***.***> wrote: *dosubot[bot]* left a comment (cloudnative-pg/plugin-barman-cloud#1091) <#1091 (comment)> @HussainBarakat <https://github.com/HussainBarakat> glad to hear you're ready to test — that'll be valuable. On the design direction: the project has already committed to the *per-command-field pattern* rather than a single global field. There's an open (unmerged) PR pair that covers two of the remaining gaps: - cloudnative-pg/barman-cloud#249 <cloudnative-pg/barman-cloud#249> adds ShowAdditionalCommandArgs and ListAdditionalCommandArgs to DataBackupConfiguration, along with Append* helpers wired into GetBackupList / GetBackupByName via executeQueryCommand. - cloudnative-pg/plugin-barman-cloud#924 <#924> is the sister PR that exposes those as new CRD fields ( showAdditionalCommandArgs, listAdditionalCommandArgs) under spec.configuration.data. It depends on #249 <#249> merging first and a barman-cloud release being cut. This extends the existing set of per-command fields — data.additionalCommandArgs, wal.archiveAdditionalCommandArgs, wal.restoreAdditionalCommandArgs, and data.restoreAdditionalCommandArgs [1] <cloudnative-pg/barman-cloud#249> — rather than replacing them with a single shared field. That said, your two specific pain points — barman-cloud-check-wal-archive and barman-cloud-backup-delete — still don't have PRs. CheckBackupDestination calls BarmanCloudCheckWalArchiveOptions directly with no additional-args plumbing [2] <https://github.com/cloudnative-pg/plugin-barman-cloud/blob/3958ee480531f08cfab3958a759186dd7f90480d/internal/cnpgi/common/check.go>, and DeleteBackupsByPolicy has the same gap (which is also what #1049 <#1049> needs for --batch-size on NetApp ONTAP). There is precedent for extending BarmanCloudCheckWalArchiveOptions — it recently gained a WithTimeline functional option in barman-cloud#212 <cloudnative-pg/barman-cloud#212> — so adding a checkAdditionalCommandArgs / deleteAdditionalCommandArgs would follow the same shape. Once #249 <#249> /#924 <#924> ship, the listAdditionalCommandArgs field should at least fix your barman-cloud-backup-list failures (retention pruning). The barman-cloud-check-wal-archive preflight check would still need its own field. I don't have visibility into a timeline for #249 <#249>/#924 <#924> merging — neither PR has maintainer review comments yet. But they're the ones to watch for your use case. *To reply, just mention @dosu <https://go.dosu.dev/dosubot?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=reply-with-mention&utm_term=cloudnative-pg%2Fplugin-barman-cloud>.* ------------------------------ Share context across your team and agents. Try Dosu <https://dosu.dev?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-tagline&utm_term=cloudnative-pg%2Fplugin-barman-cloud> . [image: Leave Feedback] <https://app.dosu.dev/response-feedback?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-feedback&utm_term=cloudnative-pg%2Fplugin-barman-cloud&message_id=d39c6a4a-7a17-4362-addd-2410443676ba> [image: Learn about plugin-barman-cloud with Dosu] <https://github.dosu.com/cloudnative-pg/plugin-barman-cloud?utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-learn-repo&utm_term=cloudnative-pg%2Fplugin-barman-cloud> [image: Add Dosu to your team] <https://app.dosu.dev/signup?referrer=openSource&source=github-footer&utm_source=github&utm_medium=bot-comment&utm_campaign=github-comment-footer-20260415&utm_content=knowledge-infrastructure-add-team&utm_term=cloudnative-pg%2Fplugin-barman-cloud> — Reply to this email directly, view it on GitHub <#1091?email_source=notifications&email_token=AUYBZJ6ZAUO5SBKSECVPRLL5M2WB3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGMYTCNRQHA3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5493116086>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUYBZJ3ZZ5GAEL66F77747T5M2WB3AVCNFSNUABFKJSXA33TNF2G64TZHM4DMMRTGQ2DAMZTHNEXG43VMU5TKMZQHE2DONJRGQ22C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AUYBZJ6U2LHYYNSDLIXSXKT5M2WB3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGMYTCNRQHA3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AUYBZJ26RZPKUCD5ZPNCUDT5M2WB3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBZGMYTCNRQHA3KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[dosubot]

@HussainBarakat that's a reasonable ask, but I should be upfront: I can't file PRs or write code myself. What I can do is lay out exactly what the change would look like based on the WithTimeline precedent, so you or another contributor can pick it up.

Following the shape of barman-cloud#212 (which added CheckWalArchiveOpts / WithTimeline as functional options), a checkAdditionalCommandArgs feature would need:

1. In the barman-cloud module (pkg/archiver/archiver.go): extend CheckWalArchiveOpts with an AdditionalCommandArgs []string field, and add a WithAdditionalCommandArgs(args []string) CheckWalArchiveOption functional option — same pattern as WithTimeline [1]. Inside BarmanCloudCheckWalArchiveOptions, after the existing --timeline handling, append the new args using the same dedup logic already in appendAdditionalCommandArgs so plugin-managed flags can't be overridden. Today that function only appends --endpoint-url, cloud-provider flags, destination path, and server name — no additional-args hook at all [2].

2. On the CRD side (api/v1/objectstore_types.go in plugin-barman-cloud): add a checkAdditionalCommandArgs field under spec.configuration.wal, alongside the existing archiveAdditionalCommandArgs and restoreAdditionalCommandArgs. Then update CheckBackupDestination in internal/cnpgi/common/check.go to pass archiver.WithAdditionalCommandArgs(...) when calling BarmanCloudCheckWalArchiveOptions — mirroring how PR #843 wired in WithTimeline.

That's two PRs (barman-cloud + plugin-barman-cloud), same structure as the #249 / #924 pair for showAdditionalCommandArgs / listAdditionalCommandArgs [3]. The barman-cloud-backup-delete gap (needed for #1049) would follow the identical pattern in DeleteBackupsByPolicy, but that's separate from your blocker [4].

I don't see any existing draft or maintainer commitment to this specific field yet — #249/#924 are the only in-flight per-command-field work I found [3]. If you want to submit the companion PRs yourself, the shape above should line up cleanly with what's already merged for WithTimeline and in-flight for show/list.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.