Improved the "Observability" section to better describe the Prometheus
metrics exposed by the Barman Cloud Plugin via the instance manager.
Added a mapping table in the "Verify your metrics" step to show the
transition from in-core metrics (`cnpg_collector_*`) to the new
plugin-based metrics (`barman_cloud_cloudnative_pg_io_*`).
Closes#473Closescloudnative-pg/cloudnative-pg#8902
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
BREAKING CHANGE: All RBAC resource names have been renamed with
consistent prefixes to prevent naming conflicts with other cluster
components.
Users must migrate their existing installations by deleting old
resources and applying the new manifest. See the migration guide for
detailed instructions (when the 0.8.0 will be published):
https://cloudnative-pg.io/plugin-barman-cloud/resource-name-migration/Closes#395
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Jonathan Battiato <jonathan.battiato@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Co-authored-by: Jonathan Battiato <jonathan.battiato@enterprisedb.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
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>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| golang | | patch | `1.25.2` -> `1.25.3` |
| golang | stage | patch | `1.25.2` -> `1.25.3` |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Enabled.
♻ **Rebasing**: Never, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/cloudnative-pg/plugin-barman-cloud).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xNDMuMSIsInVwZGF0ZWRJblZlciI6IjQxLjE0My4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJhdXRvbWF0ZWQiLCJuby1pc3N1ZSJdfQ==-->
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
The Renovate pip-compile provider is not running due to some options in
the requirements.txt that are set to `None`, which is the actual default.
```
DEBUG: pip-compile: extracted command from header (repository=local)
"fileName": "containers/sidecar-requirements.txt",
"argv": [
"pip-compile",
"--allow-unsafe",
"--cert=None",
"--client-cert=None",
"--generate-hashes",
"--index-url=None",
"--output-file=sidecar-requirements.txt",
"--pip-args=None",
"--strip-extras",
"sidecar-requirements.in"
],
"commandType": "pip-compile"
DEBUG: pip-compile: option not handled (repository=local)
"option": "--allow-unsafe"
WARN: pip-compile error (repository=local)
"matchedFile": "containers/sidecar-requirements.txt",
"errorMessage": "Option --cert=None not supported (yet)"
```
Removing the options fixes the run.
Signed-off-by: Marco Nenciarini <marco.nenciarini@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>
