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

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

Aperta
  • Qualcosa non va?
#918 2 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
42/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
aws, go, postgresql
Ambito
backend, cloud

Direzione di ricerca

La issue nomina ObjectStore, instanceSidecarConfiguration, l’operatore barman-cloud-plugin e una replica bloccata su 1/2 Ready; inizia tracciando come viene applicata questa configurazione quando un pod non è in condizioni sane. Riproduci l’errore di checksum AWS con le variabili d’ambiente mostrate e una replica bloccata, quindi verifica che la configurazione in sospeso venga applicata senza eliminare manualmente il pod.

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

Descrizione

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.

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.