ArchiveStatus is an empty struct, so the CRD ships a status subresource with no fields in it. Nothing in the Kubernetes API says when the last backup completed, which repository it went into, or whether archiving currently works against the configured path.
The CNPG fields that used to answer this are gone for plugins: lastSuccessfulBackup and firstRecoverabilityPoint are deprecated with "the field is not set for backup plugins" (cloudnative-pg/cloudnative-pg#8051), and the barman plugin ran into the same thing (cloudnative-pg/cloudnative-pg#11248). It worked around it by publishing ObjectStore.status.serverRecoveryWindow.
Where this bites us: we run a Crossplane control plane that provisions clusters and publishes backup health to tenants. Repository paths change on major upgrades and when encryption is toggled, and after such a change ContinuousArchiving stays True from the old repository. With no status on Archive we had to infer "a backup landed in the current repository" from the lastTransitionTime of the LastBackupSucceeded condition. That field carries no repository identity, so it is a guess that happens to work.
Three fields would cover it: last successful backup time, oldest recoverable point, and the repository the stanza writes to now.
#69 exposes similar data as Prometheus metrics, which is useful for alerting but not for a controller reconciling against the API. #32 and #19 ask for the same information from the user side.
We can send a PR once you're happy with the field names.
ArchiveStatusis an empty struct, so the CRD ships astatussubresource with no fields in it. Nothing in the Kubernetes API says when the last backup completed, which repository it went into, or whether archiving currently works against the configured path.The CNPG fields that used to answer this are gone for plugins:
lastSuccessfulBackupandfirstRecoverabilityPointare deprecated with "the field is not set for backup plugins" (cloudnative-pg/cloudnative-pg#8051), and the barman plugin ran into the same thing (cloudnative-pg/cloudnative-pg#11248). It worked around it by publishingObjectStore.status.serverRecoveryWindow.Where this bites us: we run a Crossplane control plane that provisions clusters and publishes backup health to tenants. Repository paths change on major upgrades and when encryption is toggled, and after such a change
ContinuousArchivingstaysTruefrom the old repository. With no status onArchivewe had to infer "a backup landed in the current repository" from thelastTransitionTimeof theLastBackupSucceededcondition. That field carries no repository identity, so it is a guess that happens to work.Three fields would cover it: last successful backup time, oldest recoverable point, and the repository the stanza writes to now.
#69 exposes similar data as Prometheus metrics, which is useful for alerting but not for a controller reconciling against the API. #32 and #19 ask for the same information from the user side.
We can send a PR once you're happy with the field names.