Wrong `ObjectStore` key logged when the backup object store can't be retrieved in the instance sidecar
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 88/100
Línea de trabajo
Revisa internal/cnpgi/instance/backup.go en Backup y internal/cnpgi/instance/metrics.go en Collect. Compara la clave pasada a GetBarmanObjectKey() con la clave registrada en cada registro de error y, a continuación, verifica que ambas rutas informen de la clave de ObjectStore de backup solicitada cuando la búsqueda falla.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
In the instance sidecar, two code paths fetch the cluster's backup ObjectStore with GetBarmanObjectKey(), but their error log reports GetRecoveryBarmanObjectKey():
internal/cnpgi/instance/backup.go (Backup):
var objectStore barmancloudv1.ObjectStore
if err := b.Client.Get(ctx, configuration.GetBarmanObjectKey(), &objectStore); err != nil {
contextLogger.Error(err, "while getting object store", "key", configuration.GetRecoveryBarmanObjectKey())
return nil, err
}
internal/cnpgi/instance/metrics.go (Collect) has the same lines.
So when the lookup fails, the key field names a different object from the one that was requested:
- on a cluster without a recovery source (the usual case),
RecoveryBarmanObjectNameis empty, sokeyhas an empty name; - on a cluster bootstrapped from an
ObjectStorethroughexternalClusters,keynames the recoveryObjectStore, which exists, pointing the reader at the wrong object.
Impact
Low, but confusing. The error message itself (for example objectstores.barmancloud.cnpg.io "s3-store" not found, or ... is forbidden) still has the right name, so the information is in the log line. But the structured key field contradicts it, and anything that filters or alerts on key gets the wrong value. Collect runs on every metrics scrape, so a missing or forbidden ObjectStore repeats the misleading line on every scrape.
This is the same kind of problem as #539/#504, which were about the operator pre-hook in reconciler.go. These two lines are on the instance side and weren't covered there.
History
The backup.go line dates from e4735a2 (#83, "separate recovery object store from replica source"). The metrics.go one was added in 33172b6 (#459) with the same lines. Open PR #1076 touches the surrounding code in backup.go but leaves this line as it is.
Proposed fix
Log configuration.GetBarmanObjectKey() in both places, the key that is actually passed to Get. I'm happy to send the PR.
How this was found
While working on #1140 on my fork, I ran an AI code review (Claude Code) over my change. It flagged the mismatched key in backup.go, even though my change didn't touch that line. I then searched the code base for the same pattern, which found the copy in metrics.go, and confirmed both on main by reading the code. I haven't triggered the failing lookup on a live cluster, so the error messages quoted above are examples, not captured output.
I used an AI assistant (Claude) to help find this and draft this issue, as the AI policy asks for disclosure.
- Lenguaje dominante
- Go
- Estrellas
- 198
- Forks
- 81
- Merge medio
- 4 d 13 h
- PR fusionados (30 d)
- 19
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de cloudnative-pg/plugin-barman-cloud
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
cloudnative-pg/plugin-barman-cloud#1117 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
data.compression rejects zstd although barman-cloud-backup supports itPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
cloudnative-pg/plugin-barman-cloud#1104 · 4 reacciones ·
Los mantenedores suelen responder en 1 día
-
Add RBAC aggregation labels to ObjectStore editor/viewer ClusterRolesPosiblemente ocupada @stefanpeknik la tomó hace 20 días. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
cloudnative-pg/plugin-barman-cloud#1102 ·
Los mantenedores suelen responder en 1 día
-
Object store definition missing runAsUser and runAsGroupPosiblemente ocupada @gustabowill la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 25/100
cloudnative-pg/plugin-barman-cloud#1145 ·
Los mantenedores suelen responder en 1 día
-
Credentials embedded in `endpointURL` are written in clear text to the instance sidecar logsAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
cloudnative-pg/plugin-barman-cloud#1143 ·
Los mantenedores suelen responder en 1 día
Todos los issues de cloudnative-pg/plugin-barman-cloud
Issues similares
-
L: github:actions L: php:composer
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
dependabot/dependabot-core#16493 ·
Los mantenedores suelen responder en 1 día
-
Controller pods on default limits CrashLoopBackOff and constantly reclaim memoryPosiblemente ocupada @brsmnv la tomó hoy. Abiertobug
Dificultad 2/5 Menos de una hora Aptitud para principiantes 68/100
ironcore-dev/ironcore-net#560 ·
Los mantenedores suelen responder en 1 día
-
3 registry records that cannot resolve for any client, and a caution about single-pass dead countsAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
modelcontextprotocol/registry#1692 ·
Los mantenedores suelen responder en 6 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
mark3labs/mcp-go#1039 · 1 comentario ·
Los mantenedores suelen responder en 8 días