Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Changes to ObjectStore spec do not get applied until after the cluster is healthy

Open
#918 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Quiet
Tech stack
aws, go, postgresql
Domain
backend, cloud

Research direction

The issue names ObjectStore, instanceSidecarConfiguration, the barman-cloud-plugin operator, and a stuck 1/2 Ready replica; start by tracing how that configuration is applied when a pod is unhealthy. Reproduce the AWS checksum failure with the shown environment variables and a blocked replica, then verify that the outstanding configuration is applied without manually deleting the pod.

Written by the indexing model from the issue text.

Description

bug

We had an issue yesterday where we updated QNAP QuObjects, causing some change to the way S3 is handled. The resultant error from barman cloud was:

ERROR: Barman cloud WAL archiver exception: An error occurred (InvalidDigest) 
when calling the PutObject operation: The Content-MD5 or checksum value that 
you specified is not valid.

The fix is already mentioned in the documentation, where we add the following to the object store:

---
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
spec:
  configuration:
     ...
  instanceSidecarConfiguration:
      env:
        - name: AWS_REQUEST_CHECKSUM_CALCULATION
          value: when_required
        - name: AWS_RESPONSE_CHECKSUM_VALIDATION
          value: when_required

and I can confirm this works perfectly. However. Because one of the pods is stuck (1/2 Ready, blocked on the error above) the update never gets applied. What I had to do was apply the fix and then manually delete that one stuck pod (3-node cluster, this pod was a replica).

I think this is a bug, just because this configuration change was specifically required to resolve the issue I was having (S3 semantics changed). It's a little more complicated, here, because it seems like I had a primary switchover (perhaps due to similar S3-related errors) which left a bunch of WALs waiting to get uploaded. Would be good to see if there's a way this could be improved such that the barman-cloud-plugin operator is able to detect the S3-related failure and apply outstanding configuration.

Dominant language
Go
Stars
192
Forks
75
Avg merge
1d 3h
Merged PRs (30d)
17

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudnative-pg/plugin-barman-cloud

All issues in cloudnative-pg/plugin-barman-cloud

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.