cloudnative-pg / cloudnative-pg/plugin-barman-cloud
Changes to ObjectStore spec do not get applied until after the cluster is healthy
- Langage dominant
- Go
- Étoiles
- 191
- Forks
- 72
- Merge moyen
- 1 j 16 h
- PR mergées (30 j)
- 18
Description
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:
```yaml
---
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.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
L’issue mentionne ObjectStore, instanceSidecarConfiguration, l’opérateur barman-cloud-plugin et une réplique bloquée à 1/2 Ready ; commencez par retracer la manière dont cette configuration est appliquée lorsqu’un pod n’est pas sain. Reproduisez l’échec de checksum AWS avec les variables d’environnement indiquées et une réplique bloquée, puis vérifiez que la configuration en attente est appliquée sans supprimer manuellement le pod.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- aws, go, postgresql
- Domaine
- backend, cloud
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- À clarifier
- Accessibilité débutants
- 42/100