Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the documentation and release notes for version 1.22.0 of the Percona Operator for MongoDB, including the deprecation of MongoDB 6.0 support.
Changes:
- Updated version references from 1.21.2 to 1.22.0 across configuration files
- Added comprehensive release notes documenting new features, improvements, and bug fixes for version 1.22.0
- Updated Split Horizon documentation to reflect automatic DNS record certificate generation
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| variables.yml | Updated release version to 1.22.0, removed MongoDB 5.0 version, and added 1.22.0 release date |
| docs/expose.md | Updated Split Horizon documentation to reflect automatic certificate generation for DNS records |
| docs/annotations.md | Added documentation for the kubectl.kubernetes.io/restartedAt annotation used for PVC restarts |
| docs/RN/Kubernetes-Operator-for-PSMONGODB-RN1.22.0.md | Added complete release notes for version 1.22.0 with features, improvements, and bug fixes |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
a222b2a to
cbfc169
Compare
cbfc169 to
8dcd064
Compare
8dcd064 to
87079c3
Compare
| ### Backup and restore | ||
|
|
||
| * [Restore into clusters with different replica set names using remapping](#restore-to-a-cluster-with-different-replica-set-names) | ||
| * [Configure a longer PBM startup deadline to prevent false backup failures](#configurable-deadline-for-pbm-to-start-backups) |
There was a problem hiding this comment.
| * [Configure a longer PBM startup deadline to prevent false backup failures](#configurable-deadline-for-pbm-to-start-backups) | |
| * [Configure a maximum PBM startup window to prevent false backup failures](#configurable-deadline-for-pbm-to-start-backups) |
|
|
||
| * [Restore into clusters with different replica set names using remapping](#restore-to-a-cluster-with-different-replica-set-names) | ||
| * [Configure a longer PBM startup deadline to prevent false backup failures](#configurable-deadline-for-pbm-to-start-backups) | ||
| * [Use native MinIO support for S3-compatible storage](#native-minio-support-as-a-backup-storage) |
There was a problem hiding this comment.
| * [Use native MinIO support for S3-compatible storage](#native-minio-support-as-a-backup-storage) | |
| * [Add support for `minio` remote storage type in Percona Backup for MongoDB](#native-minio-support-as-a-backup-storage) |
There was a problem hiding this comment.
Why in PBM? PBM has it already, we add this feature for the Operator
There was a problem hiding this comment.
In that case Operator added the support for the new PBM settings. Operator doesn't interact directly with minio storage service via native minio SDK (it's PBM that it does).
There was a problem hiding this comment.
Ok anyway I'd go with the use case: Use the minio storage type for backups to S3-compatible storage services
|
|
||
| See our [documentation](../logrotate.md) for step-by-step instructions for each option. | ||
|
|
||
| ### Configurable deadline for PBM to start backups |
There was a problem hiding this comment.
| ### Configurable deadline for PBM to start backups | |
| ### Configurable maximum window to start PBM backups |
|
|
||
| You can now configure how long the Operator waits for PBM to report that a backup has begun. Instead of relying on a fixed timeout of 120 seconds, you can tune this value to match your cluster's performance characteristics. | ||
|
|
||
| This deadline is controlled by the `startingDeadlineSeconds` option in the Custom Resource. |
There was a problem hiding this comment.
| This deadline is controlled by the `startingDeadlineSeconds` option in the Custom Resource. | |
| The maximum window duration is controlled by the `startingDeadlineSeconds` option in the Custom Resource. |
There was a problem hiding this comment.
@hors I don't like the "deadline" word here. I'd use timeout instead.
In K8s, "deadline" term usually refers to CronJob schedule misses. Since we are actually measuring the duration the Operator should wait for a PBM response, backupStartTimeoutSeconds (or a similar name) would be more intuitive. It prevents users from confusing it with CronJob logic and aligns with how K8s handles Probe timeouts. It makes the CR feel more 'native' and less 'custom'. Can we change the setting name?
There was a problem hiding this comment.
We've agreed with Slava to keep the startingDeadlineSeconds.
| * [Restore into clusters with different replica set names using remapping](#restore-to-a-cluster-with-different-replica-set-names) | ||
| * [Configure a longer PBM startup deadline to prevent false backup failures](#configurable-deadline-for-pbm-to-start-backups) | ||
| * [Use native MinIO support for S3-compatible storage](#native-minio-support-as-a-backup-storage) | ||
| * [Verify TLS for S3 storage with your own CA certificates (MinIO type)](#use-your-own-ca-certificates-for-tls-verification-with-custom-s3-storage) |
There was a problem hiding this comment.
I'd like us to use "private" instead of "custom" to sound more professional. Also "private CA" is more widely used term in that case.
| * [Verify TLS for S3 storage with your own CA certificates (MinIO type)](#use-your-own-ca-certificates-for-tls-verification-with-custom-s3-storage) | |
| * [Verify TLS communication for a S3-compatible storage with a private CA certificates](#use-private-certificate-authorities-for-tls-communication-with-s3-compatible-storage-services) |
|
|
||
| ### Vault integration for system user password management | ||
|
|
||
| You can now integrate the Operator with HashiCorp Vault for system user password management. This allows organizations to centralize password management while keeping the Operator responsible for applying those passwords to the database. |
There was a problem hiding this comment.
@hors can we also mention OpenBao as they are compatible?
There was a problem hiding this comment.
I believe we haven't tested OpenBao
There was a problem hiding this comment.
@hors can we do tests for that? I'd rather like we are consistent in supporting Vaults - from Hashicorp or OpenBao - this is also very in-line with our recent partnership with Openbao.
There was a problem hiding this comment.
We have a plan to include testing of OpenBao for all operators. For psmdb we can do it in 1.23.0.
There was a problem hiding this comment.
That's fair enough. Thanks!
| Learn more about the workflow and the setup in our [documentation](../system-users-vault.md). | ||
|
|
||
|
|
||
| ## Deprecation, rename and removal |
There was a problem hiding this comment.
I think that's a good place to announce 6.0 deprecation, too
|
|
||
| ## CRD Changes | ||
|
|
||
| * The `.spec.startingDeadlineSeconds` option has now a minimum value of 1 and the default value of 120 |
There was a problem hiding this comment.
| * The `.spec.startingDeadlineSeconds` option has now a minimum value of 1 and the default value of 120 | |
| * The `.spec.startingDeadlineSeconds` option has now a minimum value of `1` and the default value of `120` |
| The Operator was developed and tested with the following software: | ||
|
|
||
| * Percona Server for MongoDB 6.0.27-21, 7.0.28-15, and 8.0.17-6 | ||
| * Percona Backup for MongoDB 2.11.0 |
There was a problem hiding this comment.
As we added minio support - I guess we tested with 2.12.0 right?
| * Percona Backup for MongoDB 2.11.0 | |
| * Percona Backup for MongoDB 2.12.0 |
There was a problem hiding this comment.
SW, platforms and images are not updated yet. Will update once I have this info from the team
f4efc17 to
4159ef4
Compare
| * Reduce false backup failures when PBM starts slowly under load | ||
| * Give PBM enough time to start in environments with limited CPU or memory | ||
| * Get more predictable backup flows where PBM and the Operator stay in sync | ||
| * Reduce the risk of OOM errors during backups |
There was a problem hiding this comment.
right... but that setting doesn't reduce the disk of OOM errors at all. In that case user experienced OOM error due to a logical backup being run (it's resource-intensive). Because there was OOM - their backup has failed. Additionally, if there a lot of data in MongoDB it takes a longer time for PBM to query that for logical backups and update the status so the operator knows it has started properly.
| * Get more predictable backup flows where PBM and the Operator stay in sync | ||
| * Reduce the risk of OOM errors during backups | ||
|
|
||
| ### Native MinIO support as a backup storage |
There was a problem hiding this comment.
I'm open for proposals. We could have it better maybe with "Better support of S3-compatible remote storages for backup and restore with dedicated minio storage type"
4159ef4 to
d8cec9f
Compare
2f5d36b to
ec4f2e2
Compare
| * [Better service mesh compatibility with automatic `appProtocol: mongo` on services](#ensure-smooth-integration-with-service-meshes) | ||
| * [Improved GitOps workflows via automated CRD upgrades from a dedicated Helm chart](#automatic-crd-updates-for-helm-installations) | ||
| * [Disable authentication for dev/test environments to speed up setup](#speed-up-development-or-testing-pipelines-by-disabling-authentication) | ||
| * [Integrate with HashCorp Vault for system users management](#) |
There was a problem hiding this comment.
Why this has no href?
No description provided.