Adds the safety and robustness improvements identified during
review of the recommended-labels feature, all on the managed
Role and RoleBinding paths.
Labels: per-key overwrite. Keys the plugin manages overwrite
existing values; unrelated keys (anything outside the desired
set) are left alone. The plugin owns these objects exclusively
— OwnerReference points to the Cluster CR, the Pre hook
reconciles them on every call, and there is no realistic path
for an external manager (Helm, Kustomize, ArgoCD, …) to ever
touch these per-Cluster runtime-generated objects, so per-key
overwrite is the correct policy and version labels follow
plugin upgrades naturally.
Subjects: additive. The plugin guarantees its own ServiceAccount
Subject is bound, but never removes Subjects added by other
actors. A Subject is a grant of access; silently revoking
access an admin granted (e.g. a debugging ServiceAccount) is
the wrong default. This is intentionally asymmetric to the
label policy.
RoleRef: immutable in Kubernetes; a Patch cannot fix it.
Divergence at the canonical name is corruption regardless of
who wrote the existing object — fail loudly so the operator
notices and deletes the RoleBinding, and the next Pre call
recreates it correctly.
AlreadyExists tolerance: EnsureRoleBinding called c.Create
directly when Get returned NotFound and propagated whatever
Create returned. That's noisy on plugin pod startup: the
controller-runtime client is cache-backed by default, and during
the warm-up window the informer cache can return NotFound for a
RoleBinding that is actually present on the API server. The
follow-up Create then hits AlreadyExists and the whole Pre hook
returned an error to the cnpg-i framework. Mirror the pattern
used by ensureRoleExists: split the exists-or-create concern
into getOrCreateRoleBinding, swallow AlreadyExists, and re-Get
to return the racing winner so the caller can fall through to
reconcile.
Optimistic locking on patches: patchRole already wrapped its
Get+Patch in retry.RetryOnConflict, but used client.MergeFrom
which doesn't include resourceVersion — so the API server never
returns 409 and the retry never fires. Switch both Patch sites
to client.MergeFromWithOptions(WithOptimisticLock{}) so the
retry actually does what its caller assumes it does.
EnsureRoleBinding gets the same retry wrapper for parity.
Single-Get steady state: the previous structure did one Get to
check existence and a second Get inside the retry loop, even
when the object was already present and matched desired.
reconcileRoleBinding now receives the existing object as input
and uses it on the first attempt, only Get-ing again on actual
conflict-driven retries.
Helpers: extract mergeLabels (per-key overwrite), mergeSubjects
(additive append), containsSubject (semantic deep-equal), and
keep labelsNeedUpdate / roleBindingNeedsUpdate as no-Patch
short-circuits whose result mirrors the merge helpers exactly.
Tests: cover fresh creation, steady-state no-op (via Patch
interceptor counter, more reliable than the previous
ResourceVersion comparison which depended on fake-client RV
semantics that aren't part of the controller-runtime contract),
unrelated-label preservation, stale-label refresh, additive
subjects with user-added entries, AlreadyExists race during
pod startup (deterministic via interceptor), divergent
RoleRef error path, and the upgrade scenario for objects that
predate the recommended-labels feature.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
The original PR set the recommended labels to:
app.kubernetes.io/name="postgresql" (utils.AppName, the cnpg
operator's identity)
app.kubernetes.io/version=<cluster PG major>
Per issue #545 the plugin's RBAC objects should advertise the
plugin's own identity:
app.kubernetes.io/name="barman-cloud-plugin"
app.kubernetes.io/version=<plugin semver>
Use metadata.Data.Version for the version value (always set,
never conditional on cluster image), drop the cnpg
GetPostgresqlMajorVersion lookup (irrelevant to plugin RBAC and
fragile against the cnpg PostgresImageName default), and extract
the plugin-local AppLabelValue and ManagedByLabelValue constants
so test and production share a single source of truth. The
labels_test.go helper now also asserts the version's value, not
just the key.
Document on metadata.ClusterLabelName that it's a discovery
contract for objectstore_controller.go (which selects on the
key), so the dual-labeling scheme (the legacy cluster label
alongside the K8s recommended labels) is explicit and the
legacy key cannot be silently removed by a later cleanup.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
The package is already named specs, the file content is label
construction, and a separate metadata package exists at
internal/cnpgi/metadata; labels.go describes the file directly
without the package-name collision. BuildLabels also matches
the verb convention already used elsewhere in the package
(BuildRole, BuildRoleBinding, BuildRoleRules).
No behavior change.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
When an ObjectStore's credentials change (e.g., secret rename), the
RBAC Role granting the Cluster's ServiceAccount access to those
secrets was not updated because nothing triggered a Cluster
reconciliation.
Implement the ObjectStore controller's Reconcile to detect affected
Roles and update their rules directly, without needing access to
Cluster objects. The controller lists Roles by a label set by the
Pre hook, inspects their rules to find which ObjectStores they
reference, fetches those ObjectStores, and patches the rules to
match the current specs.
Replace the custom setOwnerReference helper with
controllerutil.SetControllerReference. Add dynamic CNPG scheme
registration (internal/scheme) to the operator, instance, and
restore managers.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.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>
Skip the catalog maintenance cycle when the plugin is not configured for
backups on the cluster, which happens when the plugin is used for
restore only.
Closes#774
Signed-off-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
The operator was not announcing the TYPE_INSTANCE_SIDECAR_INJECTION
capability so the CNPG operator did not consider the plugin enabled
for instance pods. The instance manager never queried the plugin's
metrics endpoint, and the barman_cloud_cloudnative_pg_io_* metrics
were missing entirely.
This bug was masked when isWALArchiver was set to true in the plugin
configuration, because the backward compatibility code in CNPG would
mark the plugin as enabled as a side-effect. Users with isWALArchiver
set to false (or omitted) never saw the new metrics.
Closes#682
Signed-off-by: Kenny Root <kenny@the-b.org>
This commit adds support for the DefaultAzureCredential authentication
mechanism in Azure Blob Storage. Users can now use the
`useDefaultAzureCredentials` option to enable Azure's default credential
chain, which automatically discovers and uses available credentials in
the following order
1. Environment Variables (Service Principal)
2. Managed Identity
3. Azure CLI
4. Azure PowerShell
This is particularly useful when running on Azure Kubernetes Service
(AKS) with Workload Identity, eliminating the need to explicitly store
credentials in Kubernetes Secrets.
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Gabriele Fedi <gabriele.fedi@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>
Enable the LeaderElectionReleaseOnCancel option in the controller
manager to fix a deadlock issue during RollingUpdate deployments with
leader election enabled.
Without this setting, the old pod holds the leader lease during
shutdown, preventing the new pod from becoming ready. This creates a
deadlock where Kubernetes won't terminate the old pod because the new
pod isn't ready, and the new pod can't become ready because it can't
acquire the lease.
With LeaderElectionReleaseOnCancel enabled, the old pod voluntarily
releases the lease when it receives a shutdown signal, allowing the new
pod to acquire leadership immediately and become ready, enabling smooth
rolling updates.
Closes#419
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
When the end of the WAL stream is reached, the parallel WAL restore
feature attempts to predict the names of subsequent WAL files to restore
and records the first missing WAL file.
On high-availability (HA) replicas, if PostgreSQL requests the first
missing WAL file, the code returns an error status that prompts
PostgreSQL to switch to streaming replication.
Currently, the code assumes a `wal_segment_size` of 16MB for predicting
the next WAL file names. If the configured WAL segment size exceeds
16MB, it may request non-existent WAL files. For instance, with 16MB
segments, the names would range from `000000010000000100000000` to
`0000000100000001000000FF` before moving to the next segment. For 1GB
segments, they would range from `000000010000000100000000` to
`000000010000000100000003`.
With the assumption of a 16MB segment size, the code will not find the
WALs from `000000010000000100000004` to `0000000100000001000000FF`.
While this assumption does not affect HA replicas - which can shift to
streaming mode - it's problematic for a PostgreSQL instance seeking
consistency after a restore, as the restore process will fail.
This patch disables end-of-wal file marker management during
replication, addressing restore issues for backups that were:
1. using a custom WAL file segment size
2. utilizing parallel WAL recovery
3. initiated on one WAL segment and concluded on a different one
Fixes: #603
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
The plugin now returns a 404 status code when a requested WAL file does
not exist in the object store.
This prevents misleading log entries such as "Error while handling gRPC
request" for expected missing-file scenarios.
The `ErrEndOfWALStreamReached` now returns `OutOfRange` error.
The `ErrMissingPermissions` now returns `FailedPrecondition` error.
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 commit adds a new `logLevel` field to the plugin configuration,
allowing users to select the desired log verbosity for the instances
(e.g. error, warning, info, debug, trace).
Closes#514
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Introduce the `additionalContainerArgs` field in the `ObjectStore` resource.
It allows specifying an optional list of command-line arguments appended to
the Barman Cloud sidecar container at startup.
Closes#501
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
* make sure objects expire after DefaultTTLSeconds
* make cached objects have GKV information
* fix cache retrieval and removal logic
Closes#502
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>
Add the required missing permission to operate in k8s
environments where the Admission Controller
Plugin "OwnerReferencesPermissionEnforcement"
is enabled.
Signed-off-by: Gabriele Fedi <gabriele.fedi@enterprisedb.com>
Introduce two new Prometheus metrics sourced from the Barman Cloud plugin:
- `barman_cloud_cloudnative_pg_io_first_recoverability_point`
- `barman_cloud_cloudnative_pg_io_last_available_backup_timestamp`
These metrics supersede the following deprecated CNPG metrics:
- `cnpg_collector_first_recoverability_point`
- `cnpg_collector_last_available_backup_timestamp`
Depends on: https://github.com/cloudnative-pg/cloudnative-pg/pull/8033
Relates to: #380
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
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>
There was mistake on the object used to compare the ObjectStore, we were
using a type Secret instead of ObjectStore.
Also, make it more clear the logic to retrieve the cached objects by getting
the cached objects when are cached.
Signed-off-by: Jonathan Gonzalez V. <jonathan.gonzalez@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>
