CloudNativePG is moving the bootstrap of new instances from dedicated
Jobs into the instance pod itself (cloudnative-pg/cloudnative-pg#11319):
the restore that used to run in a recovery Job now happens in-process
inside the instance pod before PostgreSQL starts. The sidecar shipped in
that pod must therefore answer the same Restore RPC the operator sends
over the plugin sockets, so the instance mode now registers the
restore-job hooks and advertises the restore-job service capability.
A cluster that only bootstraps from an object store, without continued
archiving, previously received no sidecar at all in its instance pods;
under the new flow that leaves the bootstrap without a plugin socket,
both for the Restore RPC and for `wal-restore` during the recovery
replay. The injection condition is widened to match what the plugin
configuration already considers valid, so recovery-only clusters get the
sidecar too.
The sidecar is dropped once the instance's bootstrap completes
(cluster.Status.CurrentPrimary set), which triggers one deterministic
rollout to remove it, accepted rather than engineered around since it
uses the same switchover/restart machinery as any other pod-spec change.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
The Role bound to the instance service account is built from the object
stores the Cluster refers to, so a Backup naming any other store fails
with a forbidden error on objectstores. The object store selection of a
Backup is therefore unusable on its own.
Add the additionalBarmanObjectNames parameter, a comma separated list of
stores that take part in the RBAC and in the certificates of the
instances while nothing is routed to them, so that a Backup can name one
of them.
Closes#611
Assisted-by: Claude Opus 5
Signed-off-by: Ildar Gilyazev <horiganmikle@gmail.com>
The operator relays the parameters of a Backup resource to the plugin in
the BackupRequest, but the plugin builds its configuration from the
Cluster alone. A Backup asking for a different object store is therefore
written to the cluster one, and it completes without any warning, so the
mistake surfaces only when the archive turns out to be empty.
Apply the parameters of the Backup on top of the configuration derived
from the Cluster, so that barmanObjectName and serverName select the
destination of that single backup.
Closes#611
Assisted-by: Claude Opus 5
Signed-off-by: Ildar Gilyazev <horiganmikle@gmail.com>
Replica clusters that use `pg_basebackup` as the bootstrap method and
stream WAL from an object store were not getting the barman sidecar
injected, causing WAL restore to fail silently. These clusters are now
handled correctly.
---------
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
When referring to the same ObjectStore with custom TLS certificates
multiple times, the plugin was adding the same volume projection two
times. This lead to a wrong Job definition.
This patch makes the plugin add a sidecar to replica cluster Pods that
are using the plugin to get WALs, even if the plugin itself is not used
for WAL archiving.
Closes: #329
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
This patch enables the barman-cloud plugin to function with an operator
that is structurally identical to CNPG but works with a different API group.
It achieves this through lenient decoding of the provided CNPG resources
and injecting the detected GVK into the sidecar, enabling it to correctly
encode and decode the Kubernetes resources.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
