You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add Kubernetes Operator v1.6.0 documentation and content
✨ Enhancement📝 Documentation
Walkthroughs
Description
• Add comprehensive v1.6.0 documentation for Kubernetes Operator
• Document new features including PodDisruptionBudget, improved health checks, online license checks
• Provide installation guides for Helm, OpenShift, and OLM deployment methods
• Include detailed API reference, networking, backup, and certificate management guides
• Fix certificate authority secret documentation for clarity on empty string handling
Diagram
flowchart LR
A["v1.6.0 Release"] --> B["Getting Started Guide"]
A --> C["Installation Methods"]
A --> D["API Reference"]
A --> E["Operations Guides"]
B --> F["README with Features"]
C --> G["Helm/OpenShift/OLM"]
D --> H["Resource Types & Config"]
E --> I["Deployment Examples"]
E --> J["Backup & Certificates"]
E --> K["Advanced Networking"]
1. ReadOnly-Replicas term inconsistent✓ Resolved📘 Rule violation⚙ Maintainability
Description
The new v1.6.0 docs use ReadOnly-Replicas/ReadOnlyReplicas instead of the consistent generic
term read-only replicas. This violates the requirement to normalize terminology consistently
across the documentation.
+| `replicas` _integer_ | Yes | Number of nodes in a database cluster. May be 1, 3, 5, or, for [standalone ReadOnly-Replicas][ror], it may be 0. |
Evidence
Rule 3 requires consistent casing/terminology. The added KurrentDBSpec table introduces
standalone ReadOnly-Replicas and later references ReadOnlyReplicas, which conflicts with the
otherwise-used read-only replicas terminology.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The documentation uses inconsistent terminology for read-only replicas (e.g., `ReadOnly-Replicas`, `ReadOnlyReplicas`) instead of consistent reader-facing wording.
## Issue Context
Rule requires consistent capitalization/terminology across headings and prose.
## Fix Focus Areas
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[21-21]
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[36-36]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. Kurrent DB naming inconsistent✓ Resolved📘 Rule violation⚙ Maintainability
Description
The new v1.6.0 docs mix KurrentDB with Kurrent DB/kurrentdb in prose and descriptions. This
violates the requirement to keep terminology consistently normalized throughout the docs.
+| `constraints` _[KurrentDBConstraints][d6]_ | No | Scheduling constraints for the Kurrent DB pod. |+| `readOnlyReplicas` _[KurrentDBReadOnlyReplicasSpec][d7]_ | No | Read-only replica configuration for the Kurrent DB Cluster. |+| `archiver` _[KurrentDBArchiverSpec][d8]_ | No | Archiver replica configuration for the Kurrent DB Cluster. |
Evidence
Rule 3 requires consistent terminology/casing. The added content uses KurrentDB but also
introduces spaced/lowercased variants (Kurrent DB, kurrentdb) in the same document, creating
inconsistent terminology.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Inconsistent product/term formatting appears in the documentation (`KurrentDB` vs `Kurrent DB` vs `kurrentdb`).
## Issue Context
Rule requires consistent terminology in prose and descriptions.
## Fix Focus Areas
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[31-33]
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[309-311]
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[417-419]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
A grammatical error (`Kind`'s`) appears in the introduction to the resource types list.
## Issue Context
This is reader-facing documentation and should use correct grammar.
## Fix Focus Areas
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[6-6]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
4. CA keyName rules unclear 🐞 Bug≡ Correctness
Description
The updated v1.5.0 note for certificateAuthoritySecret.keyName only describes non-empty vs
empty-string behavior and no longer mentions the valid “missing/unset” case. This creates
inconsistency with the v1.6.0 reference, which documents that missing *or* empty trusts all keys,
and can mislead users configuring CA rotation.
+Note that in `certificateAuthoritySecret`, only `.name` needs to be non-empty. If `.keyName` is+non-empty, only that Secret key will be mounted into the pod as a CA. If it is set to the empty+string (`""`), all Secret keys will be mounted as CAs, which allows for rotating CAs without+downtime, by trusting both old and new CAs for a period of time. `.privateKeyName` is deprecated+and ignored.
Evidence
The reworded v1.5.0 note now only talks about non-empty vs empty-string keyName, while v1.6.0
explicitly documents that keyName being missing OR empty results in trusting all keys—highlighting
the v1.5.0 ambiguity/inconsistency.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The v1.5.0 documentation note for `certificateAuthoritySecret.keyName` became ambiguous after rewording: it discusses `keyName` being non-empty vs explicitly set to `""`, but doesn’t explicitly say what happens if `keyName` is omitted.
## Issue Context
v1.6.0’s `CertificateAuthoritySecret` table explicitly states that if `keyName` is missing or empty, all keys are trusted. v1.5.0 should match that wording to avoid confusing readers and introducing version-to-version inconsistency.
## Fix Focus Areas
- docs/server/kubernetes-operator/v1.5.0/getting-started/resource-types.md[226-230]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
5. scheulde typo in table✓ Resolved📘 Rule violation≡ Correctness
Description
The v1.6.0 configuration reference misspells “schedule” as scheulde in the
KurrentDBBackupScheduleSpec table. This violates the requirement for correct grammar and will be
published verbatim, reducing documentation clarity and searchability.
+| `suspend` _boolean_ | No | While true, pauses the creation of new backups for this scheulde. |
Evidence
Rule 4 requires correct grammar/spelling in documentation, and the cited section of the generated
v1.6.0 resource-types reference table for backup schedules contains the misspelling scheulde in
the KurrentDBBackupScheduleSpec table, demonstrating a clear spelling error in user-facing
content.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The v1.6.0 documentation contains a typo in the `KurrentDBBackupScheduleSpec` table where “schedule” is misspelled as `scheulde`; this should be corrected to meet grammar/spelling requirements and maintain documentation quality.
## Issue Context
This is user-facing, generated reference documentation that will be rendered verbatim to end users; typos reduce clarity, documentation quality, and searchability.
## Fix Focus Areas
- docs/server/kubernetes-operator/v1.6.0/getting-started/resource-types.md[372-379]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
6. No newline at EOF 🐞 Bug⚙ Maintainability
Description
The newly added v1.6.0 operations README is missing a trailing newline at end-of-file. This can
break markdown/text linting and some POSIX-oriented tooling in CI pipelines.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`docs/server/kubernetes-operator/v1.6.0/operations/README.md` is missing a final newline, which some linters and tooling treat as an error.
## Issue Context
The PR diff marks this file with `No newline at end of file`.
## Fix Focus Areas
- docs/server/kubernetes-operator/v1.6.0/operations/README.md[9-11]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
rb-kurrent
force-pushed
the
operator-v1-6-0-content
branch
from
This includes 1.6.0 features and also substantial typo detection + correction.