DEV-877 Operator v1.3.1 docs #915
Merged
Conversation
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
Docs Preview
|
Docs Preview
|
Deploying documentation with
|
| Latest commit: |
5ad5cbb
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://82f1b619.documentation-21k.pages.dev |
| Branch Preview URL: | https://v1-4-0.documentation-21k.pages.dev |
rb-kurrent
force-pushed
the
v1.4.0
branch
2 times, most recently
from
72ae1c7 to
a76c7f9
Compare
| # Install the CRDs | ||
| kubectl apply -f kurrentdb-operator/templates/crds | ||
| helm template -s 'templates/crds/*.yaml' kurrentdb-operator \ | ||
| --set operator.license.file= --set operator.license.key= \ |
Member
There was a problem hiding this comment.
Maybe add placeholders for the file and the key so people don't try to execute the command as-is?
Contributor
Author
There was a problem hiding this comment.
No, this command is meant to be run as-is. This version didn't have defaults or proper none handling, so the secrets template would fail without license data, even if you were only trying to generate the crds out of the template.
Member
There was a problem hiding this comment.
Ah got it, it's the old version
Contributor
Author
There was a problem hiding this comment.
I added a brief explanation in the comment above this line.
|
|
||
| ::: caution | ||
| If `crds.enabled` transitions from `true` to `false` during an upgrade or rollback, the CRDs will be | ||
| removed from the cluster, and all KurrentDB and KurrentDBBackup resources will be deleted as well! |
Member
There was a problem hiding this comment.
I guess any other resource types will be removed too, maybe add this "all resources managed by KurrentDB Operator like KurrentDB and KurrentDBBackup will be removed.
| ### Cluster-wide | ||
|
|
||
| In cluster-wide mode, the Operator tracks Kurrent resources across **all** namespaces and requires `ClusterRole`. Helm creates the ClusteRole automatically. | ||
| In cluster-wide mode, the Operator tracks Kurrent resources across **all** namespaces and requires `ClusterRole`. Helm creates the ClusterRole automatically. |
Member
There was a problem hiding this comment.
Add fences around ClusterRole for consistency
| is not supported. | ||
|
|
||
| The recommended workaround is to combine [self-signed certificates within the cluster]( | ||
| #three-node-secure-cluster-using-self-signed-certificates)) with an Ingress that does TLS |
Member
There was a problem hiding this comment.
Two parenthesis, does it work?
Contributor
Author
There was a problem hiding this comment.
well sure it worked, it was just an extra paren of plain text on the output. Thanks for catching that.
| If you set the value of `crds.keep` to `false` (the default is `true`), helm upgrades and rollbacks | ||
| can result in data loss. If `crds.keep` is `false` and `crds.enabled` transitions from `true` | ||
| to `false` during an upgrade or rollback, the CRDs will be removed from the cluster, and all | ||
| KurrentDB and KurrentDBBackup resources will be deleted as well! |
Member
There was a problem hiding this comment.
Same here (see above) about other resources.
Contributor
Author
There was a problem hiding this comment.
yes I got all four cautions 👍
Version 1.3.0 is totally broken, due to the "support helm install --skip-crds" change, which is revoked for version 1.3.1. Also, upon further inspection, there were various parts of the docs for all existing versions that were just plain wrong. - The `Three Node Secure Cluster (using LetsEncrypt)` example has never worked. LetsEncrypt won't issue certificates for service names and the operator doesn't yet support any other way for nodes to connect to each other. I replaced the broken examples with a note about the recommended workaround. If we can't fix the three node letsencrypt problem soon then we should publish an example of the workaround at least. - The helm instructions were silent about the catastrophic data loss that could occur if you messed with crds.enabled the wrong way. - The installation instructions claim that by removing the --set=crds.enabled=true flag that CRDs would not be installed, except the default value of crds.enabled is also true, so that isn't correct. - The helm upgrade instructions did not include --reuse-values or --reset-then-reuse-values, but they did include a --set, which means helm would default to --reset-values, which means all values set during installation would be discarded. The instructions falsely claimed that values set during installation would be preserved.
alexeyzimarev
approved these changes
Aug 22, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Version 1.3.0 is totally broken, due to the "support helm install
--skip-crds" change, which is revoked for version 1.3.1.
Also, upon further inspection, there were various parts of the docs
for all existing versions that were just plain wrong.
The
Three Node Secure Cluster (using LetsEncrypt)example has neverworked. LetsEncrypt won't issue certificates for service names and
the operator doesn't yet support any other way for nodes to connect to
each other. I replaced the broken examples with a note about the
recommended workaround. If we can't fix the three node letsencrypt
problem soon then we should publish an example of the workaround at
least.
The helm instructions were silent about the catastrophic data loss
that could occur if you messed with crds.enabled the wrong way.
The installation instructions claim that by removing the
--set=crds.enabled=true flag that CRDs would not be installed, except
the default value of crds.enabled is also true, so that isn't
correct.
The helm upgrade instructions did not include --reuse-values or
--reset-then-reuse-values, but they did include a --set, which means
helm would default to --reset-values, which means all values set
during installation would be discarded. The instructions falsely
claimed that values set during installation would be preserved.