The bootstrap that used to run in a dedicated recovery Job now happens
in-process inside the instance pod before PostgreSQL starts, so the sidecar
shipped in that pod must answer the same Restore RPC the operator sends over
the plugin sockets. The instance mode now registers the restore job hooks and
advertises the restore-job service capability so the operator can reach them.
A cluster that only bootstraps from an object store, without continued
archiving, previously received no sidecar in its instance pods; the injection
condition is widened to match what the plugin configuration already considers
valid, so those clusters get the sidecar too.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Archive() and the restore job hook each re-derived, on their own,
whether to verify the WAL archive destination is empty, by reading a
Cluster annotation and, for Archive, an on-disk marker file. That
decision belongs to the operator, which already tracks both the
annotation and the marker file's lifecycle.
Honor cnpg-i's new WALArchiveRequest/RestoreRequest field
CheckEmptyWalArchive when the operator sets it: obey it directly,
without re-inspecting the marker file. Only fall back to the previous
annotation-and-marker-file logic when talking to an operator that
predates this field.
Related: cloudnative-pg/cnpg-i#353 adds the field this depends on;
cloudnative-pg/cloudnative-pg#11216 is the operator-side counterpart.
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
An `ObjectStore` already lets users tack extra command-line flags onto
three of the four `barman-cloud-*` invocations: `barman-cloud-backup`
via
`data.additionalCommandArgs`, `barman-cloud-wal-archive` via
`wal.archiveAdditionalCommandArgs`, and `barman-cloud-wal-restore` via
`wal.restoreAdditionalCommandArgs`. The fourth — `barman-cloud-restore`,
the actual data-restore step in PITR and recovery-from-object-store —
has had no
equivalent, which is exactly the gap reported in #821 (the asker wanted
a longer `--read-timeout` for slow restores from S3).
This PR fills that gap by adding
`spec.configuration.data.restoreAdditionalCommandArgs` and wiring it
into the recovery job hook. In `restoreDataDir`,
the user-supplied flags are appended after the cloud-provider options
and `--endpoint-url` but before the positional `(destinationPath,
serverName,
backupID, pgdata)` arguments — same shape as the other three knobs. The
library's existing append/dedup logic still wins on conflicts, so users
can't
accidentally override flags the plugin already sets (`--cloud-provider`,
`--endpoint-url`, etc.).
Closes#821
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@gmail.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@gmail.com>
The restore manager used a hardcoded scheme registration that ignored
CUSTOM_CNPG_GROUP and CUSTOM_CNPG_VERSION, causing restore jobs to fail
under non-standard CNPG API groups.
Extract `generateScheme()` into `common.GenerateScheme()` and use it
from both instance and restore managers.
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>
Logging the full environment of the plugin container can potentially
result in an unnecessarily long log line, but perhaps more importantly
the credentials are visible as well.
Signed-off-by: Andreas Mårtensson <andreas.martensson@svt.se>
In the in-tree barman-cloud implementation, the check for an empty WAL
archive is performed both immediately after the restore process and when the
first WAL file is archived.
Previously, the plugin-based implementation only performed this check after
restore, skipping it during archiving of the first WAL. This patch restores
parity with the in-tree behavior by ensuring the check is also performed
during WAL archiving.
Closes: #457
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Upgrade Barman to 3.13.0 and adjust the argument order in
`barman-cloud-restore` to work around the regression described in
cloudnative-pg/cloudnative-pg#6932.
Closes#208
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This commit makes the Barman cloud plugin support the enforcement of
retention policy as provided by the barman-cloud tool suite.
The first recoverability point and the last successful backup are
shown in the status of the ObjectStore resource for each involved
server name.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
This patch enables the use of custom CA certificates when connecting
to the object store in the barman-cloud plugin. The certificates are
injected into the sidecar via a projected volume and used by the
barman-cloud tool suite.
If the barman object name or the key name changes, users must trigger
a Pod rollout to apply the new values.
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
