docs(ignite): refresh guides to 2.18.0 and fix bugs found by executing them#1000
Conversation
…g them Executed the Ignite guides on a live KubeDB v2026.6.19 cluster and fixed the discrepancies found. Confirmed each fix against the source-of-truth repos (apimachinery API/ops/autoscaler types, ignite operator, cli) or observed cluster behavior. Highlights: - Standardize the ignite version to 2.18.0 across all guides and example YAMLs (update-version now upgrades 2.17.0 to 2.18.0; 2.16.0 is not in the catalog). Verified 2.18.0 provisions and reaches Ready. - Fix wrong service ports 11211 (Memcached copy-paste) to the real Ignite ports 8080/10800/47500/47100 in the monitoring guides and appbinding. - Fix the stats port name prom-http to metrics and the builtin agent annotation prometheus.io/operator to prometheus.io/builtin. - Remove MongoDB/PgBouncer copy-paste residue: MogoDBOpsRequest, mongo-ca, mg-issuer, mops-* op names, RestartReplicaSet (real reason is RestartNodes), databaseRef name mongo and the non-existent readinessCriteria/oplogMaxLagSeconds fields, connection-pooler component label, and pool_passwd prose. - Fix broken internal links concepts/*/index.md to concepts/*.md. - Fix command typos that error: ubectl to kubectl, dmeo to demo, capital-I Igniteopsrequest, PgBouncer shortname pp to ig, and wrong object names in verify/cleanup commands (ig to ig-standalone, etc.). - Fix the config secret name from <name>-config to the real <name>-<uid-suffix>, the AppBinding scheme tcp to http, the DoNotTerminate error output, and the Delete-policy leftover secrets (only the auth secret survives). - Fix concept/field errors: helathChecker to healthChecker, add RotateAuth and StorageMigration to the opsrequest type list, resourceDiffPercentage default 10% to 50%, mis-indented IgniteVersion sample YAML, and several name typos. Verified on cluster: provisioning and connection (sqlline) on 2.18.0, and the Restart, HorizontalScaling, VerticalScaling, RotateAuth, and UpdateVersion (2.17.0 to 2.18.0) ops requests, plus builtin-Prometheus stats service. The corrected example YAMLs pass server-side dry-run validation. Signed-off-by: Tamal Saha <tamal@appscode.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR updates Ignite documentation examples and guides to reference version 2.18.0, while also correcting several resource names, link targets, field references, and sample output strings across Ignite tutorials. ChangesIgnite documentation updates
Estimated code review effort: 2 (Simple) | ~12 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/guides/ignite/private-registry/using-private-registry.md`:
- Around line 41-47: The IgniteVersion example is missing the exporter image
override, so the private-registry setup is incomplete. Update the example under
the IgniteVersion fields to include spec.exporter.image alongside spec.db.image
and version, using the mirrored PRIVATE_REGISTRY exporter image referenced by
the guide. Keep the change within the same example block so readers can see both
db and exporter images configured together.
In `@docs/guides/ignite/scaling/vertical-scaling/vertical-scaling.md`:
- Around line 137-140: The example bullets in the vertical scaling guide have
incorrect field/value text for the ops request reference. Update the
descriptions around the `spec.databaseRef.name`, `spec.type`, and
`spec.verticalScaling.node` examples so they correctly state that
`databaseRef.name` points to the `ig` database, use the lowercase
`spec.verticalScaling.node` path, and avoid mixing the `igops-vscale`
ops-request name into the database reference explanation. Keep the surrounding
`vertical-scaling.md` guidance aligned with the existing `OpsRequest` field
names and examples.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 88008ca7-abe3-4f5d-b300-be9b8d48c2d8
📒 Files selected for processing (39)
docs/examples/ignite/custom-config/custom-ignite.yamldocs/examples/ignite/custom-config/custom-podtemplate.yamldocs/examples/ignite/custom-config/ignite-without-tolerations.yamldocs/examples/ignite/custom-config/node-selector.yamldocs/examples/ignite/custom-config/sidecar-container.yamldocs/examples/ignite/custom-config/with-tolerations.yamldocs/examples/ignite/custom-rbac/ig-custom-db-two.yamldocs/examples/ignite/custom-rbac/ig-custom-db.yamldocs/examples/ignite/monitoring/builtin-prom-ignite.yamldocs/examples/ignite/monitoring/ignite.yamldocs/examples/ignite/private-registry/demo-2.yamldocs/examples/ignite/quickstart/demo.yamldocs/guides/ignite/autoscaler/compute/compute-autoscale.mddocs/guides/ignite/autoscaler/storage/overview.mddocs/guides/ignite/autoscaler/storage/storage-autoscale.mddocs/guides/ignite/concepts/appbinding.mddocs/guides/ignite/concepts/autoscaler.mddocs/guides/ignite/concepts/ignite-version.mddocs/guides/ignite/concepts/ignite.mddocs/guides/ignite/concepts/opsrequest.mddocs/guides/ignite/custom-configuration/using-config-file.mddocs/guides/ignite/custom-configuration/using-podtemplate.mddocs/guides/ignite/custom-rbac/using-custom-rbac.mddocs/guides/ignite/monitoring/overview.mddocs/guides/ignite/monitoring/using-builtin-prometheus.mddocs/guides/ignite/monitoring/using-prometheus-operator.mddocs/guides/ignite/private-registry/using-private-registry.mddocs/guides/ignite/quickstart/quickstart.mddocs/guides/ignite/reconfigure-tls/reconfigure-tls.mddocs/guides/ignite/reconfigure/overview.mddocs/guides/ignite/reconfigure/reconfigure.mddocs/guides/ignite/restart/restart.mddocs/guides/ignite/rotate-auth/overview.mddocs/guides/ignite/rotate-auth/rotateauth.mddocs/guides/ignite/scaling/horizontal-scaling/horizontal-scaling.mddocs/guides/ignite/scaling/vertical-scaling/vertical-scaling.mddocs/guides/ignite/update-version/overview.mddocs/guides/ignite/update-version/update-version.mddocs/guides/ignite/volume-expansion/volume-expansion.md
💤 Files with no reviewable changes (1)
- docs/guides/ignite/concepts/autoscaler.md
| name: 2.18.0 | ||
| spec: | ||
| db: | ||
| image: PRIVATE_REGISTRY/ignite:2.17.0 | ||
| image: PRIVATE_REGISTRY/ignite:2.18.0 | ||
| securityContext: | ||
| runAsUser: 70 | ||
| version: 2.17.0 | ||
| version: 2.18.0 |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate the guide and the IgniteVersion schema/CRD references.
git ls-files | rg 'docs/guides/ignite/private-registry/using-private-registry\.md|igniteversion|crd|schema|exporter' || true
# Show the relevant guide section with line numbers.
sed -n '1,220p' docs/guides/ignite/private-registry/using-private-registry.md
# Search for exporter image handling in docs and schema-like files.
rg -n --hidden --glob '!**/.git/**' 'exporter\.image|EXPORTER_IMAGE|spec\.exporter|IgniteVersion' .Repository: kubedb/docs
Length of output: 1945
🌐 Web query:
kubedb docs IgniteVersion exporter image private registry spec.exporter.image CRD schema
💡 Result:
In KubeDB, the spec.exporter.image field is defined within the IgniteVersion Custom Resource Definition (CRD) and specifies the container image used for exporting Prometheus metrics [1][2]. To use a private registry with KubeDB for Ignite, you must perform the following steps: 1. Push Required Images: Push the required database and exporter images (specified in the IgniteVersion object) from the official KubeDB repositories to your private container registry [1]. 2. Update IgniteVersion: Modify the IgniteVersion object in your cluster to point to your private registry for the images [1]. You can view the current images by checking your IgniteVersion objects: kubectl get igniteversions -o=custom-columns=NAME:.metadata.name,EXPORTER_IMAGE:.spec.exporter.image [1] Update the spec.exporter.image field to reference the image path within your private registry [1]. 3. Configure Authentication: When deploying the Ignite resource, include the imagePullSecrets field in your Ignite manifest to provide the necessary credentials for accessing your private registry [1][3]. Example structure for updating an IgniteVersion: apiVersion: catalog.kubedb.com/v1alpha1 kind: IgniteVersion metadata: name: spec: db: image: <PRIVATE_REGISTRY>/ignite: exporter: image: <PRIVATE_REGISTRY>/ignite-exporter: version: Example for the Ignite deployment: apiVersion: kubedb.com/v1alpha2 kind: Ignite metadata: name: spec: version: "" imagePullSecrets: - name: ... [1][3]
Citations:
- 1: https://kubedb.com/docs/v2026.2.26/guides/ignite/private-registry/using-private-registry/
- 2: https://kubedb.com/docs/v2026.6.19/guides/ignite/concepts/ignite-version/
- 3: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/
🌐 Web query:
site:kubedb.com IgniteVersion spec.exporter.image private registry
💡 Result:
To use a private registry for the exporter image defined in an IgniteVersion CRD, you must ensure that the required images are available within your private registry [1][2]. The process involves the following steps: 1. Push Images to Private Registry: You must pull the necessary database and exporter images from the KubeDB Docker Hub account and push them to your own private container registry [1][2]. The spec.exporter.image field in the IgniteVersion object specifically requires the image path for the Prometheus metrics exporter [3]. 2. Configure KubeDB: After the images are available in your private registry, you must configure KubeDB to pull from it. This is typically handled by setting up a global or local image pull secret and ensuring the IgniteVersion points to the correct, custom image path in your registry [1][2]. For detailed, version-specific instructions on configuring KubeDB to use a private registry with Ignite, refer to the official KubeDB documentation for your current deployment [1][2].
Citations:
- 1: https://kubedb.com/docs/v2026.4.27/guides/ignite/private-registry/using-private-registry/
- 2: https://kubedb.com/docs/v2026.2.26/guides/ignite/private-registry/using-private-registry/
- 3: https://kubedb.com/docs/v2026.6.19/guides/ignite/concepts/ignite-version/
Add spec.exporter.image to the IgniteVersion example.
The guide already tells readers to mirror EXPORTER_IMAGE, and spec.exporter.image is part of the IgniteVersion schema. Leaving it out keeps the exporter on the public registry and makes the private-registry setup incomplete.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/guides/ignite/private-registry/using-private-registry.md` around lines
41 - 47, The IgniteVersion example is missing the exporter image override, so
the private-registry setup is incomplete. Update the example under the
IgniteVersion fields to include spec.exporter.image alongside spec.db.image and
version, using the mirrored PRIVATE_REGISTRY exporter image referenced by the
guide. Keep the change within the same example block so readers can see both db
and exporter images configured together.
There was a problem hiding this comment.
Addressed in 50531f5, but not by adding spec.exporter.image: Ignite's IgniteVersion has no exporter image. IgniteVersionSpec (apimachinery apis/catalog/v1alpha1/ignite_version_types.go) only defines spec.db.image and spec.initContainer.image, and .spec.exporter.image is empty on the live catalog object. The image shown in that column is actually the init image. So I relabeled the EXPORTER_IMAGE column and prose as INIT_IMAGE (.spec.initContainer.image) and added initContainer.image to the catalog example so the init image is mirrored to the private registry too.
There was a problem hiding this comment.
@tamalsaha Thanks for the correction and for digging into IgniteVersionSpec in apis/catalog/v1alpha1/ignite_version_types.go. You're right — since IgniteVersion only exposes spec.db.image and spec.initContainer.image (no spec.exporter.image), my original suggestion to add an exporter image override was based on an incorrect assumption. Relabeling the column/prose to INIT_IMAGE and mirroring spec.initContainer.image in the catalog example is the correct fix. I'll withdraw the original suggestion.
✏️ Learnings added
Learnt from: tamalsaha
Repo: kubedb/docs PR: 1000
File: docs/guides/ignite/private-registry/using-private-registry.md:41-49
Timestamp: 2026-07-09T12:44:10.515Z
Learning: In the kubedb/docs repository, Ignite's `IgniteVersionSpec` (apimachinery `apis/catalog/v1alpha1/ignite_version_types.go`) only defines `spec.db.image` and `spec.initContainer.image` — there is no `spec.exporter.image` field, unlike some other KubeDB catalog types. Documentation for Ignite private-registry setup (e.g., `docs/guides/ignite/private-registry/using-private-registry.md`) should reference `INIT_IMAGE`/`.spec.initContainer.image` rather than an `EXPORTER_IMAGE`/`spec.exporter.image` column when mirroring images to a private registry.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
tamalsaha
left a comment
There was a problem hiding this comment.
Inline notes on the fixes, grouped by class. Each was confirmed against the source-of-truth repos (apimachinery API/ops/autoscaler types, the ignite operator, the cli) or observed on a live KubeDB v2026.6.19 cluster. Pure 2.17.0 -> 2.18.0 version bumps are not annotated individually.
| ## Find Available IgniteVersion | ||
|
|
||
| When you have installed KubeDB, it has created `IgniteVersion` crd for all supported Ignite versions. Check 0 | ||
| When you have installed KubeDB, it has created `IgniteVersion` crd for all supported Ignite versions. Check it out. |
There was a problem hiding this comment.
Fixed the garbled sentence (was Check 0).
| ```bash | ||
| $ kubectl delete ig ignite-quickstart -n demo | ||
| Error from server (Forbidden): admission webhook "ignitewebhook.validators.kubedb.com" denied the request: ignite demo/ignite-quickstart is can't terminated. To delete, change spec.deletionPolicy | ||
| The Ignite "ignite-quickstart" is invalid: spec.deletionPolicy: Invalid value: "ignite-quickstart": Can not delete as terminationPolicy is set to "DoNotTerminate" |
There was a problem hiding this comment.
Replaced with the real error KubeDB returns for a DoNotTerminate delete (verified on the cluster). The old text was a stale, ungrammatical webhook message.
|
|
||
| - `spec.replicas` is an optional field that specifies the number of desired Instances/Replicas of Ignite server. It defaults to 1. | ||
| - `spec.version` is the version of Ignite server. In this tutorial, a Ignite 2.17.0 database is going to be created. | ||
| - `spec.version` is the version of Ignite server. In this tutorial, a Ignite 2.18.0 database is going to be created. |
There was a problem hiding this comment.
Version standardized to 2.18.0 (maintainer directive; 2.18.0 is in the catalog and verified to provision and reach Ready).
| namespace: demo | ||
| port: 10800 | ||
| scheme: tcp | ||
| scheme: http |
There was a problem hiding this comment.
AppBinding scheme is http, not tcp (verified: the KubeDB-created AppBinding uses http, and GetConnectionScheme() returns http). The last-applied-config blob above also had port: 11211 (Memcached's port) corrected to 10800.
| securityContext: | ||
| runAsUser: 70 | ||
| version: 2.17.0 | ||
| kind: IgniteVersion |
There was a problem hiding this comment.
The sample YAML was mis-indented (apiVersion at column 0 with kind/metadata indented under it) = invalid YAML. Re-indented so it parses. Version/images bumped to 2.18.0 (init image ignite-init:2.18.0-v1).
| 2 | ||
| ``` | ||
| From all the above outputs we can see that the replicas of the ignite is `2`. That means we have successfully scaled up the replicas of the Ignite. | ||
| From all the above outputs we can see that the replicas of the ignite is `2`. That means we have successfully scaled down the replicas of the Ignite. |
There was a problem hiding this comment.
This is the scale-down section (3 -> 2); prose said scaled up.
| Here, | ||
|
|
||
| - `spec.databaseRef.name` specifies that we are performing vertical scaling operation on `igps-vscale` database. | ||
| - `spec.databaseRef.name` specifies that we are performing vertical scaling operation on `igops-vscale` database. |
There was a problem hiding this comment.
Name typo igps-vscale -> igops-vscale (matches the ops request CR name).
| resources: | ||
| requests: | ||
| cpu: "0.5m" | ||
| cpu: "500m" |
There was a problem hiding this comment.
cpu: 0.5m (0.5 milli-cpu) was a typo for 500m; minAllowed.cpu is 600m, so 0.5m is nonsensical.
| - `spec.compute.ignite.trigger` specifies that compute resource autoscaling is enabled for this ignite. | ||
| - `spec.compute.ignite.podLifeTimeThreshold` specifies the minimum lifetime for at least one of the pod to initiate a vertical scaling. | ||
| - `spec.compute.ignite.resourceDiffPercentage` specifies the minimum resource difference in percentage. The default is 10%. | ||
| - `spec.compute.ignite.resourceDiffPercentage` specifies the minimum resource difference in percentage. The default is 50%. |
There was a problem hiding this comment.
resourceDiffPercentage default is 50% (apimachinery autoscaling type.go), not 10%.
| - `spec.storage.ignite.scalingThreshold` specifies the scaling threshold. Storage will be scaled to `20%` of the current amount. | ||
| - `spec.storage.ignite.expansionMode` specifies the expansion mode of volume expansion `igniteOpsRequest` created by `igniteAutoscaler`. topolvm-provisioner supports online volume expansion so here `expansionMode` is set as "Online". | ||
| - `spec.storage.ignite.scalingThreshold` specifies the scaling threshold. Storage will be scaled to `30%` of the current amount. | ||
| - `spec.storage.ignite.expansionMode` specifies the expansion mode of volume expansion `igniteOpsRequest` created by `igniteAutoscaler`. topolvm-provisioner supports online volume expansion so here `expansionMode` is set as "Offline". |
There was a problem hiding this comment.
Prose now matches the YAML (expansionMode: Offline). The metadata-name typo ignite-storage-autosclaer was also fixed throughout so the get/describe/cleanup commands agree.
… vertical-scaling field refs - private-registry: Ignite's IgniteVersion has no exporter image (spec.exporter is absent; only spec.db.image and spec.initContainer.image exist). Relabel the EXPORTER_IMAGE column/prose as INIT_IMAGE (.spec.initContainer.image), and add initContainer.image to the private-registry catalog example so the init image is mirrored too. - vertical-scaling: spec.databaseRef.name points to the 'ig' database, not the ops-request name; and the field path is lowercase spec.verticalScaling.node. Signed-off-by: Tamal Saha <tamal@appscode.com>
|
Visit the preview URL for this PR (updated for commit 50531f5): https://kubedb-v2-hugo--pr1000-docs-refresh-ignite-9yl1k8fz.web.app (expires Thu, 16 Jul 2026 13:30:31 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: 0f29ae8ae0bd54a99bf2b223b6833be47acd5943 |
Ran the Ignite guides on a live KubeDB v2026.6.19 cluster as a new user would, caught every place the docs were wrong, and fixed each one against the source of truth (apimachinery API/ops/autoscaler types, the ignite operator, the cli) or observed cluster behavior. 39 files changed (28 guide docs + 11 example YAMLs, all under
docs/guides/igniteanddocs/examples/ignite).Verified on the cluster (2.18.0)
sqlline(quickstart), plus DoNotTerminate / Delete / WipeOut behavior.RestartNodes), HorizontalScaling, VerticalScaling, RotateAuth (addsusername.prev/password.prev), and UpdateVersion 2.17.0 to 2.18.0. All Successful.*-stats, portmetrics:56790, agent annotationprometheus.io/builtin.kubectl apply --dry-run=server.Fixes by class
Version refresh (maintainer directive + catalog). Standardize the ignite version to
2.18.0across all guides and example YAMLs. update-version now upgrades2.17.0to2.18.0(2.16.0is not in the catalog, so the old doc could not run). Confirmed2.18.0provisions and reaches Ready.Wrong ports / names. Service ports
11211(Memcached copy-paste) to the real Ignite ports8080/10800/47500/47100in both monitoring guides andconcepts/appbinding.md; stats port nameprom-httptometrics; builtin agent annotationprometheus.io/operatortoprometheus.io/builtin; staleVERSION 1.6.22to2.18.0; CRD name made consistent (builtin-prom-ignite).MongoDB / PgBouncer copy-paste residue.
MogoDBOpsRequesttoIgniteOpsRequest;mongo-ca/mg-issuer/mg-new-issuertoignite-ca/ig-issuer/ig-new-issuer;mops-*op names toigops-*;RestartReplicaSet/"Restarted ReplicaSet nodes" toRestartNodes/"restarted all nodes" (verified on cluster);databaseRef.name: mongotoigand removed the non-existentreadinessCriteria/oplogMaxLagSecondsfields;connection-poolercomponent label todatabase; removed PgBouncerpool_passwdprose.Broken links.
concepts/*/index.mdtoconcepts/*.md(rotate-auth, update-version).Command typos that error.
ubectltokubectl;-n dmeoto-n demo; capital-IIgniteopsrequesttoigniteopsrequest; PgBouncer shortnamepptoig; wrong object names in verify/cleanup commands (igtoig-standalone,datadir-ig-0todatadir-ig-standalone-0, autoscaler name typoautosclaertoautoscaler); capital-Igniteexample URL paths to lowercase.Field / value / concept errors (source-confirmed). config secret name
<name>-configto the real<name>-<uid-suffix>; AppBinding schemetcptohttp; DoNotTerminate error output updated to the real message; Delete-policy output now shows only the surviving auth secret;spec.monitor.argstospec.monitor.prometheus.exporter.args;monitor.prometheus.labels/.intervalto.serviceMonitor.labels/.intervaland removed the non-existentmonitor.prometheus.namespace;helathCheckertohealthChecker; addedRotateAuthandStorageMigrationto the opsrequestspec.typelist; autoscalerresourceDiffPercentagedefault10%to50%,cpu: 0.5mto500m; mis-indentedIgniteVersionsample YAML fixed; scale-down section prose "scaled up" to "scaled down"; storage-autoscaler threshold/expansionMode prose reconciled with the YAML.Coverage notes
Some guides could not be fully re-executed on this cluster (fixes are source-confirmed and, for examples, dry-run validated): volume-expansion (only a non-expandable
local-pathstorage class), monitoring/using-prometheus-operator (Prometheus operator not installed), and the autoscaler guides (autoscaler stack not installed). All other guides were executed.No em-dashes. No unrelated files touched.
Summary by CodeRabbit