Add Milvus guides#936
Open
tamalsaha wants to merge 1 commit into
Open
Conversation
Add user-facing documentation for KubeDB managed Milvus covering both Standalone and Distributed topologies: - Quickstart (standalone + distributed deployment) - Monitoring (Prometheus Operator) - TLS configuration and reconfigure-TLS (add/rotate/change-issuer/remove) - Reconfigure, Restart, Update Version - Vertical and Horizontal scaling - Rotate Auth, Volume Expansion, Storage Migration - Recommendation Engine and Compute/Storage Autoscaling All guides embed live output collected from a running cluster. Signed-off-by: Tamal Saha <tamal@appscode.com>
![kodiak-appscode[bot]](https://avatars.githubusercontent.com/in/92481?s=60&v=4){kind=small}
📝 WalkthroughWalkthroughThis PR adds a comprehensive set of new documentation pages under docs/guides/milvus, covering quickstart, monitoring, TLS configuration/reconfiguration, reconfigure, restart, rotate-auth, scaling (horizontal/vertical), storage migration, volume expansion, update-version, autoscaling (compute/storage), and recommendation engine guides, along with associated front-matter index pages and example YAML manifests. ChangesMilvus Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~20 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 14
🧹 Nitpick comments (5)
docs/guides/milvus/monitoring/yamls/distributed.yaml (1)
30-38: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider whether TLS belongs in the monitoring manifest.
The monitoring guide's distributed manifest includes a TLS configuration. If the monitoring guide is meant to be standalone, users will need the
milvus-issuerIssuer from the TLS guide to exist. Either add a prerequisite note or remove TLS from this manifest to keep concerns separated. This also applies to the standalone monitoring manifest.🤖 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/milvus/monitoring/yamls/distributed.yaml` around lines 30 - 38, The distributed monitoring manifest currently embeds TLS configuration that depends on the milvus-issuer Issuer from the TLS guide, which makes the monitoring guide non-standalone. Update the monitoring YAMLs by either removing the tls section from the distributed and standalone manifests, or add an explicit prerequisite note in the monitoring guide that points users to the TLS guide and the milvus-issuer dependency. Use the tls block in distributed.yaml as the locating symbol and apply the same decision consistently to the standalone monitoring manifest.docs/guides/milvus/monitoring/yamls/standalone.yaml (1)
28-36: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winSame TLS-in-monitoring-manifest concern as distributed.yaml: confirm TLS prerequisite or separate concerns.
🤖 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/milvus/monitoring/yamls/standalone.yaml` around lines 28 - 36, The TLS block in the monitoring manifest mixes certificate issuer setup with the monitoring service TLS settings, so please separate or guard these concerns in the standalone YAML. Update the standalone monitoring manifest to either confirm the TLS prerequisite explicitly or move the issuerRef setup into the appropriate cert-management configuration, keeping the TLS modes under the monitoring config and using the existing tls, issuerRef, external, and internal sections as the anchors.docs/guides/milvus/monitoring/using-prometheus-operator.md (1)
153-158: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winCleanup section is incomplete for distributed users.
The cleanup only shows deleting
milvus-standalone. If a user followed the distributed path, they would also need to deletemilvus-cluster. Consider adding both commands or making it generic (e.g.,kubectl delete milvus.kubedb.com -n demo --all).♻️ Suggested cleanup commands
$ kubectl delete milvus.kubedb.com -n demo milvus-standalone + $ kubectl delete milvus.kubedb.com -n demo milvus-cluster $ kubectl delete ns demo🤖 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/milvus/monitoring/using-prometheus-operator.md` around lines 153 - 158, The cleanup instructions only cover the standalone Milvus resource, so users who deployed via the distributed path may leave `milvus-cluster` behind. Update the “Cleaning up” section to use the same resource type referenced in the docs and either include both cleanup targets (`milvus-standalone` and `milvus-cluster`) or switch to a generic deletion approach in the cleanup commands so both deployment modes are handled.docs/guides/milvus/autoscaler/compute/guide.md (1)
167-168: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueUse simpler resource kind in cleanup command.
kubectl delete milvus.kubedb.comis technically valid but non-idiomatic. Preferkubectl delete milvus -n demo milvus-standalonefor consistency with other KubeDB docs and better readability.🤖 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/milvus/autoscaler/compute/guide.md` around lines 167 - 168, The cleanup command uses the fully qualified resource name, which is valid but inconsistent with the rest of the docs; update the kubectl delete invocation in the guide to use the simpler resource kind with the existing milvus-standalone resource name and namespace, keeping it aligned with other KubeDB examples and easier to read.docs/guides/milvus/volume-expansion/guide.md (1)
69-69: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueUse consistent
kubectl applystyle for YAML sources.Line 69 uses a full GitHub raw URL with the version parameter, but Line 107 uses a local filename
volume-expansion-online-standalone.yaml. For consistency and copy-paste reliability, use the same GitHub raw URL pattern for both:- $ kubectl apply -f volume-expansion-online-standalone.yaml + $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/milvus/volume-expansion/yamls/volume-expansion-online-standalone.yamlOr if the local filename is intentional (e.g., user downloaded files), add a note explaining when to use which.
Also applies to: 107-107
🤖 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/milvus/volume-expansion/guide.md` at line 69, The Milvus volume-expansion guide uses two different kubectl apply source styles, so make them consistent in the relevant apply commands referenced by the guide. Update the standalone offline and online examples so they both use the same GitHub raw URL pattern with the version parameter, or if you intend to keep the local filename in the online example, add a short note in the guide explaining when to use the downloaded file versus the raw URL. Refer to the kubectl apply commands for volume-expansion-offline-standalone and volume-expansion-online-standalone when making the change.
🤖 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/milvus/autoscaler/compute/guide.md`:
- Line 109: The docs snippet contains an unexplained 500m resource request
reference that does not appear in the example manifests, so update the
autoscaler guide text in the Milvus autoscaler compute section to either add the
standalone resource request to the referenced example or remove/rephrase the
“500m request” mention; use the surrounding MilvusOpsRequest and
compute-standalone example context to keep the explanation consistent.
In `@docs/guides/milvus/quickstart/standalone.md`:
- Around line 96-104: The quickstart manifest references the milvus-issuer TLS
issuer even though it is never created in this guide. Update the standalone
quickstart example around the tls section to either remove TLS by default, add a
clear prerequisite step that creates the issuer, or explicitly point readers to
the TLS guide as a required dependency. Keep the guidance aligned with the
existing tls.external and tls.internal configuration so the example is runnable
as written.
- Around line 179-190: The quickstart text hardcodes the rendered config secret
name with an auto-generated hash, which will vary by deployment and break
copy-paste commands. Update the examples around the secret lookup in the
standalone guide to use a dynamic selection method instead of the fixed
milvus-standalone-42559a name, ideally by filtering the Milvus config secret via
labels or a template/jsonpath approach, and keep the surrounding explanation
aligned with the rendered configuration secret and TLS secret names.
In `@docs/guides/milvus/reconfigure-tls/guide.md`:
- Around line 319-325: The cleanup section is incomplete for the distributed
workflow because it only removes the standalone Milvus resource. Update the
cleanup instructions in the “Cleaning up” section to also delete the distributed
Milvus resource created by the cluster flow, using the existing kubectl delete
pattern alongside the current milvus-standalone removal; if needed, split the
cleanup into standalone and distributed variants so both workflows are covered.
In `@docs/guides/milvus/reconfigure/guide.md`:
- Around line 39-251: The reconfigure guide reuses the same MilvusOpsRequest
name, `reconfigure-1`, for both the standalone and distributed examples in the
same namespace, which creates a collision when the second manifest is applied.
Update the distributed example to use a distinct OpsRequest identity (for
example, rename the `MilvusOpsRequest` resource and matching YAML reference) so
it does not conflict with the standalone `reconfigure-1` flow; use the
`reconfigure-standalone.yaml` and `reconfigure-distributed.yaml` examples as the
symbols to adjust.
In `@docs/guides/milvus/restart/guide.md`:
- Around line 107-126: The distributed restart example reuses the same
MilvusOpsRequest name as the standalone section, causing a conflict when the
guide is followed sequentially. Update the distributed restart example in the
restart guide so its MilvusOpsRequest metadata.name is unique from the
standalone restart manifest, and rename the referenced YAML file accordingly;
use the restart-distributed example and the MilvusOpsRequest manifest as the key
symbols to update.
In `@docs/guides/milvus/rotate-auth/guide.md`:
- Around line 128-208: The distributed rotation example reuses the same Secret
and MilvusOpsRequest names as the standalone example, so a sequential reader
will hit name collisions. Update the Milvus rotate-auth guide so the distributed
section uses distinct resource names or add cleanup between the standalone and
distributed walkthroughs, and make sure the final cleanup also deletes the
distributed Milvus resource referenced by milvus-cluster. Check the
rotate-auth-distributed.yaml example, the MilvusOpsRequest name, and the cleanup
commands together so the documented “created” outputs remain accurate.
In `@docs/guides/milvus/scaling/horizontal-scaling/guide.md`:
- Around line 45-46: The horizontal-scaling guide has a replica-count mismatch
between the prose and the YAML example; update the text around the walkthrough
to match the actual `proxy` and `streamingnode` values shown in the manifest, or
adjust the manifest to match the intended counts. Use the surrounding section in
the guide and the YAML snippet for the scale-up example to ensure the
description consistently reflects whether the sample starts at 1 or requests 2
replicas.
In
`@docs/guides/milvus/scaling/horizontal-scaling/yamls/horizontal-scaling-distributed.yaml`:
- Around line 12-13: The replica counts in the distributed Milvus scaling YAML
are inconsistent with the guide examples and verification output. Update the
values in the horizontal-scaling-distributed configuration so they match the
expected scaled state used elsewhere in the guide, or make the guide’s inline
example and verification section consistently reflect the same replica count.
Use the matching symbols proxy and streamingnode to align all references to one
value.
In `@docs/guides/milvus/tls/configure/index.md`:
- Around line 163-213: The inline distributed Milvus manifest in the TLS guide
is missing the monitoring configuration present in the referenced YAML, so
update the manifest block to match the `distributed.yaml` source or explicitly
call out the omission. Use the `spec.topology.distributed` section in this doc
snippet as the place to add the `monitor` settings, ensuring the copied example
produces the same deployment as the linked YAML.
- Around line 215-221: The cleanup section is incomplete because it only removes
the standalone Milvus resources and leaves the distributed deployment artifacts
behind. Update the “Cleaning up” commands in the TLS guide to also delete the
distributed Milvus objects created by the distributed workflow, using the same
resource names referenced in the distributed setup such as milvus-cluster and
milvus-cluster-issuer. Make the cleanup instructions comprehensive so they cover
both standalone and distributed deployments, keeping the same kubectl delete
pattern used in the existing cleanup block.
In `@docs/guides/milvus/update-version/guide.md`:
- Around line 121-135: The MilvusOpsRequest example in the distributed
update-version section reuses the same metadata.name as the standalone example,
which can cause a collision if both are applied in the same namespace. Update
the example name in the distributed scenario to a distinct value in the
MilvusOpsRequest manifest, or add a clear note that it is intentionally
separate; use the existing example block and metadata.name field as the location
to adjust.
In `@docs/guides/milvus/volume-expansion/guide.md`:
- Line 136: The distributed online MilvusOpsRequest currently reuses the same
name as the standalone example, causing a collision if both are applied in one
namespace. Rename the distributed OpsRequest in the volume-expansion guide to a
unique value, and update any surrounding guide text that refers to it so the
example names stay consistent. Also fix the cleanup instructions in the same
guide to remove the distributed resource as well as the standalone one by
updating the cleanup block around the volume-expansion section, using the
existing MilvusOpsRequest and milvus-cluster/milvus-standalone examples as the
reference points.
In `@docs/guides/milvus/volume-expansion/overview.md`:
- Around line 50-56: The volume expansion flow in the Milvus docs currently
implies every `MilvusOpsRequest` pauses and resumes the database, which is only
true for Offline mode. Update the overview steps to distinguish the `Offline`
and `Online` paths in the `MilvusOpsRequest` volume expansion flow: for Offline,
describe validate → pause → patch PVCs → update spec → resume → mark successful;
for Online, describe validate → patch PVCs without pausing → mark successful.
Use the existing step text in the overview section to reword step 2 and step 5
so they apply only to Offline expansion.
---
Nitpick comments:
In `@docs/guides/milvus/autoscaler/compute/guide.md`:
- Around line 167-168: The cleanup command uses the fully qualified resource
name, which is valid but inconsistent with the rest of the docs; update the
kubectl delete invocation in the guide to use the simpler resource kind with the
existing milvus-standalone resource name and namespace, keeping it aligned with
other KubeDB examples and easier to read.
In `@docs/guides/milvus/monitoring/using-prometheus-operator.md`:
- Around line 153-158: The cleanup instructions only cover the standalone Milvus
resource, so users who deployed via the distributed path may leave
`milvus-cluster` behind. Update the “Cleaning up” section to use the same
resource type referenced in the docs and either include both cleanup targets
(`milvus-standalone` and `milvus-cluster`) or switch to a generic deletion
approach in the cleanup commands so both deployment modes are handled.
In `@docs/guides/milvus/monitoring/yamls/distributed.yaml`:
- Around line 30-38: The distributed monitoring manifest currently embeds TLS
configuration that depends on the milvus-issuer Issuer from the TLS guide, which
makes the monitoring guide non-standalone. Update the monitoring YAMLs by either
removing the tls section from the distributed and standalone manifests, or add
an explicit prerequisite note in the monitoring guide that points users to the
TLS guide and the milvus-issuer dependency. Use the tls block in
distributed.yaml as the locating symbol and apply the same decision consistently
to the standalone monitoring manifest.
In `@docs/guides/milvus/monitoring/yamls/standalone.yaml`:
- Around line 28-36: The TLS block in the monitoring manifest mixes certificate
issuer setup with the monitoring service TLS settings, so please separate or
guard these concerns in the standalone YAML. Update the standalone monitoring
manifest to either confirm the TLS prerequisite explicitly or move the issuerRef
setup into the appropriate cert-management configuration, keeping the TLS modes
under the monitoring config and using the existing tls, issuerRef, external, and
internal sections as the anchors.
In `@docs/guides/milvus/volume-expansion/guide.md`:
- Line 69: The Milvus volume-expansion guide uses two different kubectl apply
source styles, so make them consistent in the relevant apply commands referenced
by the guide. Update the standalone offline and online examples so they both use
the same GitHub raw URL pattern with the version parameter, or if you intend to
keep the local filename in the online example, add a short note in the guide
explaining when to use the downloaded file versus the raw URL. Refer to the
kubectl apply commands for volume-expansion-offline-standalone and
volume-expansion-online-standalone when making the change.
🪄 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: 235d559a-de88-4e85-bdfa-35e9d8d48e45
📒 Files selected for processing (85)
docs/guides/milvus/_index.mddocs/guides/milvus/autoscaler/_index.mddocs/guides/milvus/autoscaler/compute/_index.mddocs/guides/milvus/autoscaler/compute/guide.mddocs/guides/milvus/autoscaler/compute/overview.mddocs/guides/milvus/autoscaler/compute/yamls/compute-distributed.yamldocs/guides/milvus/autoscaler/compute/yamls/compute-standalone.yamldocs/guides/milvus/autoscaler/storage/_index.mddocs/guides/milvus/autoscaler/storage/guide.mddocs/guides/milvus/autoscaler/storage/overview.mddocs/guides/milvus/autoscaler/storage/yamls/storage-distributed.yamldocs/guides/milvus/autoscaler/storage/yamls/storage-standalone.yamldocs/guides/milvus/monitoring/_index.mddocs/guides/milvus/monitoring/overview.mddocs/guides/milvus/monitoring/using-prometheus-operator.mddocs/guides/milvus/monitoring/yamls/distributed.yamldocs/guides/milvus/monitoring/yamls/standalone.yamldocs/guides/milvus/quickstart/_index.mddocs/guides/milvus/quickstart/distributed.mddocs/guides/milvus/quickstart/standalone.mddocs/guides/milvus/quickstart/yamls/distributed.yamldocs/guides/milvus/quickstart/yamls/standalone.yamldocs/guides/milvus/recommendation/_index.mddocs/guides/milvus/recommendation/guide.mddocs/guides/milvus/recommendation/yamls/distributed.yamldocs/guides/milvus/recommendation/yamls/standalone.yamldocs/guides/milvus/reconfigure-tls/_index.mddocs/guides/milvus/reconfigure-tls/guide.mddocs/guides/milvus/reconfigure-tls/overview.mddocs/guides/milvus/reconfigure-tls/yamls/issuer.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-add-distributed.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-add-new-issuer-distributed.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-add-new-issuer-standalone.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-add-standalone.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-remove-distributed.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-remove-standalone.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-rotate-distributed.yamldocs/guides/milvus/reconfigure-tls/yamls/reconfigureTls-rotate-standalone.yamldocs/guides/milvus/reconfigure/_index.mddocs/guides/milvus/reconfigure/guide.mddocs/guides/milvus/reconfigure/overview.mddocs/guides/milvus/reconfigure/yamls/reconfigure-distributed.yamldocs/guides/milvus/reconfigure/yamls/reconfigure-standalone.yamldocs/guides/milvus/restart/_index.mddocs/guides/milvus/restart/guide.mddocs/guides/milvus/restart/yamls/restart-distributed.yamldocs/guides/milvus/restart/yamls/restart-standalone.yamldocs/guides/milvus/rotate-auth/_index.mddocs/guides/milvus/rotate-auth/guide.mddocs/guides/milvus/rotate-auth/overview.mddocs/guides/milvus/rotate-auth/yamls/rotate-auth-distributed.yamldocs/guides/milvus/rotate-auth/yamls/rotate-auth-standalone.yamldocs/guides/milvus/scaling/_index.mddocs/guides/milvus/scaling/horizontal-scaling/_index.mddocs/guides/milvus/scaling/horizontal-scaling/guide.mddocs/guides/milvus/scaling/horizontal-scaling/overview.mddocs/guides/milvus/scaling/horizontal-scaling/yamls/horizontal-scaling-distributed.yamldocs/guides/milvus/scaling/vertical-scaling/_index.mddocs/guides/milvus/scaling/vertical-scaling/guide.mddocs/guides/milvus/scaling/vertical-scaling/overview.mddocs/guides/milvus/scaling/vertical-scaling/yamls/vertical-scaling-distributed.yamldocs/guides/milvus/scaling/vertical-scaling/yamls/vertical-scaling-standalone.yamldocs/guides/milvus/storage-migration/_index.mddocs/guides/milvus/storage-migration/guide.mddocs/guides/milvus/storage-migration/yamls/storage-migration-distributed.yamldocs/guides/milvus/storage-migration/yamls/storage-migration-standalone.yamldocs/guides/milvus/tls/_index.mddocs/guides/milvus/tls/configure/index.mddocs/guides/milvus/tls/configure/yamls/cluster-issuer.yamldocs/guides/milvus/tls/configure/yamls/distributed.yamldocs/guides/milvus/tls/configure/yamls/issuer.yamldocs/guides/milvus/tls/configure/yamls/standalone.yamldocs/guides/milvus/tls/overview.mddocs/guides/milvus/update-version/_index.mddocs/guides/milvus/update-version/guide.mddocs/guides/milvus/update-version/overview.mddocs/guides/milvus/update-version/yamls/update-version-distributed.yamldocs/guides/milvus/update-version/yamls/update-version-standalone.yamldocs/guides/milvus/volume-expansion/_index.mddocs/guides/milvus/volume-expansion/guide.mddocs/guides/milvus/volume-expansion/overview.mddocs/guides/milvus/volume-expansion/yamls/volume-expansion-offline-distributed.yamldocs/guides/milvus/volume-expansion/yamls/volume-expansion-offline-standalone.yamldocs/guides/milvus/volume-expansion/yamls/volume-expansion-online-distributed.yamldocs/guides/milvus/volume-expansion/yamls/volume-expansion-online-standalone.yaml
| } | ||
| ``` | ||
|
|
||
| Here the recommended `target` is `cpu: 143m` / `memory: 256Mi` (the standalone idles well below its `500m` request). Because the recommendation differs from the current request by more than `resourceDiffPercentage` (10%) and stays within `minAllowed`/`maxAllowed`, the autoscaler creates a `VerticalScaling` `MilvusOpsRequest`. This is recorded in the autoscaler status as a `CreateOpsRequest` condition: |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Remove or explain the unexplained 500m reference.
The text says "the standalone idles well below its 500m request", but no 500m request is shown in the preceding compute-standalone.yaml or deployment output. Either add the initial resource request to the example manifest or remove this reference to avoid reader confusion.
🤖 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/milvus/autoscaler/compute/guide.md` at line 109, The docs snippet
contains an unexplained 500m resource request reference that does not appear in
the example manifests, so update the autoscaler guide text in the Milvus
autoscaler compute section to either add the standalone resource request to the
referenced example or remove/rephrase the “500m request” mention; use the
surrounding MilvusOpsRequest and compute-standalone example context to keep the
explanation consistent.
Comment on lines
+96
to
+104
| tls: | ||
| issuerRef: | ||
| name: milvus-issuer | ||
| kind: Issuer | ||
| apiGroup: "cert-manager.io" | ||
| external: | ||
| mode: mTLS | ||
| internal: | ||
| mode: TLS |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
TLS issuer is not created in this guide.
The manifest references issuerRef.name: milvus-issuer, but this issuer is never created in the quickstart. A reader applying this YAML verbatim will fail because the issuer does not exist. Either add a prerequisite step to create the issuer (or reference the TLS guide more prominently as a hard dependency), or change the example to disable TLS by default and move the TLS-enabled variant to the TLS guide.
🤖 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/milvus/quickstart/standalone.md` around lines 96 - 104, The
quickstart manifest references the milvus-issuer TLS issuer even though it is
never created in this guide. Update the standalone quickstart example around the
tls section to either remove TLS by default, add a clear prerequisite step that
creates the issuer, or explicitly point readers to the TLS guide as a required
dependency. Keep the guidance aligned with the existing tls.external and
tls.internal configuration so the example is runnable as written.
Comment on lines
+179
to
+190
| $ kubectl get secret -n demo | grep milvus-standalone | ||
| milvus-standalone-42559a Opaque 2 92s | ||
| milvus-standalone-auth kubernetes.io/basic-auth 2 92s | ||
| milvus-standalone-client-cert kubernetes.io/tls 4 91s | ||
| milvus-standalone-server-cert kubernetes.io/tls 3 91s | ||
|
|
||
| $ kubectl get secret milvus-standalone-auth -n demo -o jsonpath='{.data.username}' | base64 -d | ||
| root | ||
| ``` | ||
|
|
||
| The other secrets are the rendered configuration secret (`milvus-standalone-42559a`, holding `milvus.yaml` and `glog.conf`) and the TLS certificate secrets (`-server-cert`, `-client-cert`). | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Do not hardcode the auto-generated config secret suffix.
Lines 180 and 222 reference milvus-standalone-42559a, where 42559a is an auto-generated hash that will differ for every deployment. Readers copy-pasting these commands will get "not found" errors. Replace with a dynamic lookup pattern, e.g.:
kubectl get secret -n demo -l app.kubernetes.io/instance=milvus-standalone | grep -E 'milvus-standalone-[a-z0-9]+'or use jsonpath/go-template to select the config secret by label or type.
🤖 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/milvus/quickstart/standalone.md` around lines 179 - 190, The
quickstart text hardcodes the rendered config secret name with an auto-generated
hash, which will vary by deployment and break copy-paste commands. Update the
examples around the secret lookup in the standalone guide to use a dynamic
selection method instead of the fixed milvus-standalone-42559a name, ideally by
filtering the Milvus config secret via labels or a template/jsonpath approach,
and keep the surrounding explanation aligned with the rendered configuration
secret and TLS secret names.
Comment on lines
+319
to
+325
| ## Cleaning up | ||
|
|
||
| ```bash | ||
| $ kubectl delete milvusopsrequest -n demo mvops-add-tls mvops-rotate mv-change-issuer mvops-remove | ||
| $ kubectl delete milvus.kubedb.com -n demo milvus-standalone | ||
| $ kubectl delete ns demo | ||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Incomplete cleanup instructions for distributed workflow.
The cleanup section only deletes milvus-standalone, but users following the distributed section would also have created milvus-cluster. Add milvus-cluster to the cleanup command or split into standalone/distributed cleanup steps.
$ kubectl delete milvusopsrequest -n demo mvops-add-tls mvops-rotate mv-change-issuer mvops-remove
- $ kubectl delete milvus.kubedb.com -n demo milvus-standalone
+ $ kubectl delete milvus.kubedb.com -n demo milvus-standalone milvus-cluster
$ kubectl delete ns demo📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Cleaning up | |
| ```bash | |
| $ kubectl delete milvusopsrequest -n demo mvops-add-tls mvops-rotate mv-change-issuer mvops-remove | |
| $ kubectl delete milvus.kubedb.com -n demo milvus-standalone | |
| $ kubectl delete ns demo | |
| ``` | |
| ## Cleaning up | |
🤖 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/milvus/reconfigure-tls/guide.md` around lines 319 - 325, The
cleanup section is incomplete for the distributed workflow because it only
removes the standalone Milvus resource. Update the cleanup instructions in the
“Cleaning up” section to also delete the distributed Milvus resource created by
the cluster flow, using the existing kubectl delete pattern alongside the
current milvus-standalone removal; if needed, split the cleanup into standalone
and distributed variants so both workflows are covered.
Comment on lines
+39
to
+251
| ## Reconfigure Standalone Milvus | ||
|
|
||
| ### Deploy Milvus | ||
|
|
||
| Deploy a standalone Milvus and wait for it to become `Ready` (see the [standalone quickstart](/docs/guides/milvus/quickstart/standalone.md)): | ||
|
|
||
| ```bash | ||
| $ kubectl get milvuses.kubedb.com -n demo milvus-standalone | ||
| NAME VERSION STATUS AGE | ||
| milvus-standalone 2.6.11 Ready 2m | ||
| ``` | ||
|
|
||
| ### Apply the Reconfigure OpsRequest | ||
|
|
||
| We will apply a new configuration through a config secret and an inline `applyConfig`. The OpsRequest below first references a config secret (`mv-configuration`), then overrides part of it inline: | ||
|
|
||
| `reconfigure-standalone.yaml` | ||
|
|
||
| ```yaml | ||
| --- | ||
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: mv-configuration | ||
| namespace: demo | ||
| type: Opaque | ||
| stringData: | ||
| milvus.yaml: | | ||
| log: | ||
| level: debug | ||
| file: | ||
| maxAge: 20 | ||
| queryNode: | ||
| gracefulTime: 10 | ||
| dataNode: | ||
| segment: | ||
| maxSize: 400 | ||
| --- | ||
| apiVersion: ops.kubedb.com/v1alpha1 | ||
| kind: MilvusOpsRequest | ||
| metadata: | ||
| name: reconfigure-1 | ||
| namespace: demo | ||
| spec: | ||
| type: Reconfigure | ||
| databaseRef: | ||
| name: milvus-standalone | ||
| configuration: | ||
| removeCustomConfig: true | ||
| configSecret: | ||
| name: mv-configuration | ||
| applyConfig: | ||
| milvus.yaml: | | ||
| log: | ||
| level: info | ||
| file: | ||
| maxAge: 30 | ||
| queryNode: | ||
| gracefulTime: 500 | ||
| restart: "false" | ||
| timeout: 5m | ||
| apply: IfReady | ||
| ``` | ||
|
|
||
| Here, | ||
|
|
||
| - `spec.databaseRef.name` is the Milvus we are reconfiguring. | ||
| - `spec.configuration.configSecret` references a secret whose `milvus.yaml` holds configuration. | ||
| - `spec.configuration.applyConfig` merges an inline `milvus.yaml` on top — here the final, effective values for `log` and `queryNode`. | ||
| - `spec.configuration.removeCustomConfig: true` discards any previously applied custom configuration first. | ||
| - `spec.configuration.restart: "false"` requests the configuration be applied without forcing a restart. | ||
|
|
||
| ```bash | ||
| $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/milvus/reconfigure/yamls/reconfigure-standalone.yaml | ||
| secret/mv-configuration created | ||
| milvusopsrequest.ops.kubedb.com/reconfigure-1 created | ||
| ``` | ||
|
|
||
| ### Watch Progress | ||
|
|
||
| ```bash | ||
| $ kubectl get milvusopsrequest -n demo | ||
| NAME TYPE STATUS AGE | ||
| reconfigure-1 Reconfigure Successful 28s | ||
| ``` | ||
|
|
||
| ```bash | ||
| $ kubectl describe milvusopsrequest reconfigure-1 -n demo | ||
| ... | ||
| Status: | ||
| Conditions: | ||
| Message: Milvus ops-request has started to reconfigure Milvus nodes | ||
| Reason: Reconfigure | ||
| Type: Reconfigure | ||
| Message: Successfully prepared user provided apply configs | ||
| Reason: PrepareApplyConfig | ||
| Type: PrepareApplyConfig | ||
| Message: successfully reconciled the milvus with new configuration | ||
| Reason: UpdatePetSets | ||
| Type: UpdatePetSets | ||
| Message: Successfully completed reconfigure milvus | ||
| Reason: Successful | ||
| Type: Successful | ||
| Phase: Successful | ||
| Events: | ||
| Normal Starting Pausing Milvus databse: demo/milvus-standalone | ||
| Normal UpdatePetSets successfully reconciled the milvus with new configuration | ||
| Normal Starting Resuming Milvus database: demo/milvus-standalone | ||
| Normal Successful Successfully resumed Milvus database: demo/milvus-standalone for MilvusOpsRequest: reconfigure-1 | ||
| ``` | ||
|
|
||
| ### Verify the New Configuration | ||
|
|
||
| The applied values are rendered into the configuration secret's `milvus.yaml`: | ||
|
|
||
| ```bash | ||
| $ CFG=$(kubectl get secret -n demo -o name | grep -oE 'milvus-standalone-[a-f0-9]{6}' | head -1) | ||
| $ kubectl get secret $CFG -n demo -o jsonpath='{.data.milvus\.yaml}' | base64 -d | grep -A3 -E '^log:|^queryNode:' | ||
| log: | ||
| file: | ||
| maxAge: 30 | ||
| maxBackups: 20 | ||
| maxSize: 300 | ||
| ... | ||
| level: info | ||
| queryNode: | ||
| gracefulTime: 500 | ||
| port: 19536 | ||
| ``` | ||
|
|
||
| The `log.level` is now `info`, `log.file.maxAge` is `30`, and `queryNode.gracefulTime` is `500` — exactly the values supplied through `applyConfig`. | ||
|
|
||
| ## Reconfigure Distributed Milvus | ||
|
|
||
| For a distributed Milvus, the flow is identical; only `spec.databaseRef.name` points at the distributed database (`milvus-cluster`). The same `milvus.yaml` configuration is rendered into the configuration secret and propagated to every distributed role (`mixcoord`, `datanode`, `querynode`, `streamingnode`, `proxy`). | ||
|
|
||
| `reconfigure-distributed.yaml` | ||
|
|
||
| ```yaml | ||
| --- | ||
| apiVersion: v1 | ||
| kind: Secret | ||
| metadata: | ||
| name: mv-configuration | ||
| namespace: demo | ||
| type: Opaque | ||
| stringData: | ||
| milvus.yaml: | | ||
| log: | ||
| level: debug | ||
| file: | ||
| maxAge: 20 | ||
| queryNode: | ||
| gracefulTime: 10 | ||
| dataNode: | ||
| segment: | ||
| maxSize: 400 | ||
| --- | ||
| apiVersion: ops.kubedb.com/v1alpha1 | ||
| kind: MilvusOpsRequest | ||
| metadata: | ||
| name: reconfigure-1 | ||
| namespace: demo | ||
| spec: | ||
| type: Reconfigure | ||
| databaseRef: | ||
| name: milvus-cluster | ||
| configuration: | ||
| removeCustomConfig: true | ||
| configSecret: | ||
| name: mv-configuration | ||
| applyConfig: | ||
| milvus.yaml: | | ||
| log: | ||
| level: info | ||
| file: | ||
| maxAge: 30 | ||
| queryNode: | ||
| gracefulTime: 500 | ||
| restart: "false" | ||
| timeout: 5m | ||
| apply: IfReady | ||
| ``` | ||
|
|
||
| ```bash | ||
| $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/milvus/reconfigure/yamls/reconfigure-distributed.yaml | ||
| secret/mv-configuration created | ||
| milvusopsrequest.ops.kubedb.com/reconfigure-1 created | ||
|
|
||
| $ kubectl get milvusopsrequest reconfigure-1 -n demo | ||
| NAME TYPE STATUS AGE | ||
| reconfigure-1 Reconfigure Successful 21s | ||
| ``` | ||
|
|
||
| The applied configuration is rendered into the cluster's configuration secret and propagated to all roles: | ||
|
|
||
| ```bash | ||
| $ CFG=$(kubectl get secret -n demo -o name | grep -oE 'milvus-cluster-[a-f0-9]{6}' | head -1) | ||
| $ kubectl get secret $CFG -n demo -o jsonpath='{.data.milvus\.yaml}' | base64 -d | grep -A2 -E '^log:|^queryNode:|level:' | ||
| log: | ||
| file: | ||
| maxAge: 30 | ||
| maxBackups: 20 | ||
| ... | ||
| level: info | ||
| queryNode: | ||
| enableDisk: true | ||
| gracefulTime: 500 | ||
| port: 21123 | ||
| ``` | ||
|
|
||
| As with standalone, `log.level` is now `info`, `log.file.maxAge` is `30`, and `queryNode.gracefulTime` is `500`. | ||
|
|
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
OpsRequest name reconfigure-1 reused without cleanup between standalone and distributed sections.
The standalone section creates a MilvusOpsRequest named reconfigure-1 targeting milvus-standalone. The distributed section then applies another manifest with the same name reconfigure-1 but databaseRef.name: milvus-cluster, in the same demo namespace, with no intermediate kubectl delete step. If a reader follows both sections sequentially (as written), the second kubectl apply will either fail due to immutable OpsRequest spec fields or silently confuse which database it targets.
📝 Suggested fix
## Reconfigure Distributed Milvus
+
+> Before running this section, clean up the standalone example's OpsRequest: `kubectl delete milvusopsrequest -n demo reconfigure-1`Or rename the distributed OpsRequest (and its yaml file) to reconfigure-2 to avoid the collision entirely.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ## Reconfigure Standalone Milvus | |
| ### Deploy Milvus | |
| Deploy a standalone Milvus and wait for it to become `Ready` (see the [standalone quickstart](/docs/guides/milvus/quickstart/standalone.md)): | |
| ```bash | |
| $ kubectl get milvuses.kubedb.com -n demo milvus-standalone | |
| NAME VERSION STATUS AGE | |
| milvus-standalone 2.6.11 Ready 2m | |
| ``` | |
| ### Apply the Reconfigure OpsRequest | |
| We will apply a new configuration through a config secret and an inline `applyConfig`. The OpsRequest below first references a config secret (`mv-configuration`), then overrides part of it inline: | |
| `reconfigure-standalone.yaml` | |
| ```yaml | |
| --- | |
| apiVersion: v1 | |
| kind: Secret | |
| metadata: | |
| name: mv-configuration | |
| namespace: demo | |
| type: Opaque | |
| stringData: | |
| milvus.yaml: | | |
| log: | |
| level: debug | |
| file: | |
| maxAge: 20 | |
| queryNode: | |
| gracefulTime: 10 | |
| dataNode: | |
| segment: | |
| maxSize: 400 | |
| --- | |
| apiVersion: ops.kubedb.com/v1alpha1 | |
| kind: MilvusOpsRequest | |
| metadata: | |
| name: reconfigure-1 | |
| namespace: demo | |
| spec: | |
| type: Reconfigure | |
| databaseRef: | |
| name: milvus-standalone | |
| configuration: | |
| removeCustomConfig: true | |
| configSecret: | |
| name: mv-configuration | |
| applyConfig: | |
| milvus.yaml: | | |
| log: | |
| level: info | |
| file: | |
| maxAge: 30 | |
| queryNode: | |
| gracefulTime: 500 | |
| restart: "false" | |
| timeout: 5m | |
| apply: IfReady | |
| ``` | |
| Here, | |
| - `spec.databaseRef.name` is the Milvus we are reconfiguring. | |
| - `spec.configuration.configSecret` references a secret whose `milvus.yaml` holds configuration. | |
| - `spec.configuration.applyConfig` merges an inline `milvus.yaml` on top — here the final, effective values for `log` and `queryNode`. | |
| - `spec.configuration.removeCustomConfig: true` discards any previously applied custom configuration first. | |
| - `spec.configuration.restart: "false"` requests the configuration be applied without forcing a restart. | |
| ```bash | |
| $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/milvus/reconfigure/yamls/reconfigure-standalone.yaml | |
| secret/mv-configuration created | |
| milvusopsrequest.ops.kubedb.com/reconfigure-1 created | |
| ``` | |
| ### Watch Progress | |
| ```bash | |
| $ kubectl get milvusopsrequest -n demo | |
| NAME TYPE STATUS AGE | |
| reconfigure-1 Reconfigure Successful 28s | |
| ``` | |
| ```bash | |
| $ kubectl describe milvusopsrequest reconfigure-1 -n demo | |
| ... | |
| Status: | |
| Conditions: | |
| Message: Milvus ops-request has started to reconfigure Milvus nodes | |
| Reason: Reconfigure | |
| Type: Reconfigure | |
| Message: Successfully prepared user provided apply configs | |
| Reason: PrepareApplyConfig | |
| Type: PrepareApplyConfig | |
| Message: successfully reconciled the milvus with new configuration | |
| Reason: UpdatePetSets | |
| Type: UpdatePetSets | |
| Message: Successfully completed reconfigure milvus | |
| Reason: Successful | |
| Type: Successful | |
| Phase: Successful | |
| Events: | |
| Normal Starting Pausing Milvus databse: demo/milvus-standalone | |
| Normal UpdatePetSets successfully reconciled the milvus with new configuration | |
| Normal Starting Resuming Milvus database: demo/milvus-standalone | |
| Normal Successful Successfully resumed Milvus database: demo/milvus-standalone for MilvusOpsRequest: reconfigure-1 | |
| ``` | |
| ### Verify the New Configuration | |
| The applied values are rendered into the configuration secret's `milvus.yaml`: | |
| ```bash | |
| $ CFG=$(kubectl get secret -n demo -o name | grep -oE 'milvus-standalone-[a-f0-9]{6}' | head -1) | |
| $ kubectl get secret $CFG -n demo -o jsonpath='{.data.milvus\.yaml}' | base64 -d | grep -A3 -E '^log:|^queryNode:' | |
| log: | |
| file: | |
| maxAge: 30 | |
| maxBackups: 20 | |
| maxSize: 300 | |
| ... | |
| level: info | |
| queryNode: | |
| gracefulTime: 500 | |
| port: 19536 | |
| ``` | |
| The `log.level` is now `info`, `log.file.maxAge` is `30`, and `queryNode.gracefulTime` is `500` — exactly the values supplied through `applyConfig`. | |
| ## Reconfigure Distributed Milvus | |
| For a distributed Milvus, the flow is identical; only `spec.databaseRef.name` points at the distributed database (`milvus-cluster`). The same `milvus.yaml` configuration is rendered into the configuration secret and propagated to every distributed role (`mixcoord`, `datanode`, `querynode`, `streamingnode`, `proxy`). | |
| `reconfigure-distributed.yaml` | |
| ```yaml | |
| --- | |
| apiVersion: v1 | |
| kind: Secret | |
| metadata: | |
| name: mv-configuration | |
| namespace: demo | |
| type: Opaque | |
| stringData: | |
| milvus.yaml: | | |
| log: | |
| level: debug | |
| file: | |
| maxAge: 20 | |
| queryNode: | |
| gracefulTime: 10 | |
| dataNode: | |
| segment: | |
| maxSize: 400 | |
| --- | |
| apiVersion: ops.kubedb.com/v1alpha1 | |
| kind: MilvusOpsRequest | |
| metadata: | |
| name: reconfigure-1 | |
| namespace: demo | |
| spec: | |
| type: Reconfigure | |
| databaseRef: | |
| name: milvus-cluster | |
| configuration: | |
| removeCustomConfig: true | |
| configSecret: | |
| name: mv-configuration | |
| applyConfig: | |
| milvus.yaml: | | |
| log: | |
| level: info | |
| file: | |
| maxAge: 30 | |
| queryNode: | |
| gracefulTime: 500 | |
| restart: "false" | |
| timeout: 5m | |
| apply: IfReady | |
| ``` | |
| ```bash | |
| $ kubectl apply -f https://github.com/kubedb/docs/raw/{{< param "info.version" >}}/docs/guides/milvus/reconfigure/yamls/reconfigure-distributed.yaml | |
| secret/mv-configuration created | |
| milvusopsrequest.ops.kubedb.com/reconfigure-1 created | |
| $ kubectl get milvusopsrequest reconfigure-1 -n demo | |
| NAME TYPE STATUS AGE | |
| reconfigure-1 Reconfigure Successful 21s | |
| ``` | |
| The applied configuration is rendered into the cluster's configuration secret and propagated to all roles: | |
| ```bash | |
| $ CFG=$(kubectl get secret -n demo -o name | grep -oE 'milvus-cluster-[a-f0-9]{6}' | head -1) | |
| $ kubectl get secret $CFG -n demo -o jsonpath='{.data.milvus\.yaml}' | base64 -d | grep -A2 -E '^log:|^queryNode:|level:' | |
| log: | |
| file: | |
| maxAge: 30 | |
| maxBackups: 20 | |
| ... | |
| level: info | |
| queryNode: | |
| enableDisk: true | |
| gracefulTime: 500 | |
| port: 21123 | |
| ``` | |
| As with standalone, `log.level` is now `info`, `log.file.maxAge` is `30`, and `queryNode.gracefulTime` is `500`. | |
| ## Reconfigure Distributed Milvus | |
| > Before running this section, clean up the standalone example's OpsRequest: `kubectl delete milvusopsrequest -n demo reconfigure-1` | |
| For a distributed Milvus, the flow is identical; only `spec.databaseRef.name` points at the distributed database (`milvus-cluster`). The same `milvus.yaml` configuration is rendered into the configuration secret and propagated to every distributed role (`mixcoord`, `datanode`, `querynode`, `streamingnode`, `proxy`). | |
| `reconfigure-distributed.yaml` |
🤖 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/milvus/reconfigure/guide.md` around lines 39 - 251, The
reconfigure guide reuses the same MilvusOpsRequest name, `reconfigure-1`, for
both the standalone and distributed examples in the same namespace, which
creates a collision when the second manifest is applied. Update the distributed
example to use a distinct OpsRequest identity (for example, rename the
`MilvusOpsRequest` resource and matching YAML reference) so it does not conflict
with the standalone `reconfigure-1` flow; use the `reconfigure-standalone.yaml`
and `reconfigure-distributed.yaml` examples as the symbols to adjust.
Comment on lines
+163
to
+213
| ```yaml | ||
| apiVersion: kubedb.com/v1alpha2 | ||
| kind: Milvus | ||
| metadata: | ||
| name: milvus-cluster | ||
| namespace: demo | ||
| spec: | ||
| version: "2.6.11" | ||
| objectStorage: | ||
| configSecret: | ||
| name: "my-release-minio" | ||
| topology: | ||
| mode: Distributed | ||
| distributed: | ||
| streamingnode: | ||
| storageType: Durable | ||
| storage: | ||
| accessModes: | ||
| - ReadWriteOnce | ||
| storageClassName: local-path | ||
| resources: | ||
| requests: | ||
| storage: 1Gi | ||
| tls: | ||
| issuerRef: | ||
| name: milvus-issuer | ||
| kind: Issuer | ||
| apiGroup: "cert-manager.io" | ||
| external: | ||
| mode: mTLS | ||
| internal: | ||
| mode: TLS | ||
| ``` | ||
|
|
||
| After it becomes `Ready`, the certificate secrets exist, the certificates are mounted into every role's pods, and the AppBinding scheme is `https`: | ||
|
|
||
| ```bash | ||
| $ kubectl get secret -n demo | grep -E 'milvus-cluster-(server|client)-cert' | ||
| milvus-cluster-client-cert kubernetes.io/tls 4 4m | ||
| milvus-cluster-server-cert kubernetes.io/tls 3 4m | ||
|
|
||
| $ kubectl exec -n demo milvus-cluster-mixcoord-0 -c milvus -- ls /milvus/tls | ||
| ca.pem | ||
| client.key | ||
| client.pem | ||
| server.key | ||
| server.pem | ||
|
|
||
| $ kubectl get appbinding milvus-cluster -n demo -o jsonpath='{.spec.clientConfig.service.scheme}' | ||
| https | ||
| ``` |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Distributed manifest in doc omits monitoring present in referenced YAML.
The inline distributed manifest (lines 163-195) does not include the monitor section, but the actual distributed.yaml file in the yamls folder includes Prometheus Operator monitoring configuration. Users copying from the inline code block will get a different deployment than those using the linked YAML file. Align the inline manifest with the referenced YAML or add a note explaining the difference.
🤖 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/milvus/tls/configure/index.md` around lines 163 - 213, The inline
distributed Milvus manifest in the TLS guide is missing the monitoring
configuration present in the referenced YAML, so update the manifest block to
match the `distributed.yaml` source or explicitly call out the omission. Use the
`spec.topology.distributed` section in this doc snippet as the place to add the
`monitor` settings, ensuring the copied example produces the same deployment as
the linked YAML.
Comment on lines
+215
to
+221
| ## Cleaning up | ||
|
|
||
| ```bash | ||
| $ kubectl delete milvus.kubedb.com -n demo milvus-standalone | ||
| $ kubectl delete issuer -n demo milvus-issuer | ||
| $ kubectl delete secret -n demo milvus-ca | ||
| $ kubectl delete ns demo |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Cleanup section only removes standalone resources, not distributed.
The guide demonstrates both standalone and distributed TLS-secured Milvus deployments, but the cleanup commands only delete milvus-standalone, milvus-issuer, milvus-ca, and the namespace. If a user followed the distributed section, milvus-cluster and milvus-cluster-issuer (from cluster-issuer.yaml) would remain. Add cleanup commands for the distributed resources or make the cleanup section comprehensive.
🤖 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/milvus/tls/configure/index.md` around lines 215 - 221, The
cleanup section is incomplete because it only removes the standalone Milvus
resources and leaves the distributed deployment artifacts behind. Update the
“Cleaning up” commands in the TLS guide to also delete the distributed Milvus
objects created by the distributed workflow, using the same resource names
referenced in the distributed setup such as milvus-cluster and
milvus-cluster-issuer. Make the cleanup instructions comprehensive so they cover
both standalone and distributed deployments, keeping the same kubectl delete
pattern used in the existing cleanup block.
Comment on lines
+121
to
+135
| ```yaml | ||
| apiVersion: ops.kubedb.com/v1alpha1 | ||
| kind: MilvusOpsRequest | ||
| metadata: | ||
| name: milvus-update-version | ||
| namespace: demo | ||
| spec: | ||
| type: UpdateVersion | ||
| databaseRef: | ||
| name: milvus-cluster | ||
| updateVersion: | ||
| targetVersion: 2.6.11 | ||
| timeout: 5m | ||
| apply: IfReady | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
OpsRequest name collides with standalone example.
The distributed MilvusOpsRequest uses name: milvus-update-version, identical to the standalone example (lines 54-68). If a user works through both sections in the same namespace, the second apply would overwrite the first. Use a distinct name like milvus-update-version-distributed to avoid collision, or add a note that these are separate scenarios.
🤖 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/milvus/update-version/guide.md` around lines 121 - 135, The
MilvusOpsRequest example in the distributed update-version section reuses the
same metadata.name as the standalone example, which can cause a collision if
both are applied in the same namespace. Update the example name in the
distributed scenario to a distinct value in the MilvusOpsRequest manifest, or
add a clear note that it is intentionally separate; use the existing example
block and metadata.name field as the location to adjust.
| apiVersion: ops.kubedb.com/v1alpha1 | ||
| kind: MilvusOpsRequest | ||
| metadata: | ||
| name: volume-expansion-online |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Fix OpsRequest name collision and incomplete cleanup.
The distributed online MilvusOpsRequest is also named volume-expansion-online (line 136), which collides with the standalone online OpsRequest. If a user runs both examples in the same namespace, the second apply would overwrite the first. Rename the distributed example:
- name: volume-expansion-online
+ name: volume-expansion-online-distributedAnd update the guide text and cleanup accordingly.
Additionally, the cleanup section (lines 168-174) only removes milvus-standalone but not milvus-cluster. Add:
kubectl delete milvus.kubedb.com -n demo milvus-clusterOr add a note that cleanup depends on which topology was deployed.
Also applies to: 168-174
🤖 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/milvus/volume-expansion/guide.md` at line 136, The distributed
online MilvusOpsRequest currently reuses the same name as the standalone
example, causing a collision if both are applied in one namespace. Rename the
distributed OpsRequest in the volume-expansion guide to a unique value, and
update any surrounding guide text that refers to it so the example names stay
consistent. Also fix the cleanup instructions in the same guide to remove the
distributed resource as well as the standalone one by updating the cleanup block
around the volume-expansion section, using the existing MilvusOpsRequest and
milvus-cluster/milvus-standalone examples as the reference points.
Comment on lines
+50
to
+56
| The flow is: | ||
|
|
||
| 1. A user creates a `MilvusOpsRequest` of type `VolumeExpansion`. | ||
| 2. The operator validates the request and pauses the `Milvus` database. | ||
| 3. The operator patches the PVCs to the new size and waits for the CSI driver to complete the resize. | ||
| 4. The new size is reflected in `spec.storage` (standalone) or `spec.topology.distributed.streamingnode.storage` (distributed). | ||
| 5. The operator resumes the database and marks the `MilvusOpsRequest` as `Successful`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clarify that pause/resume only applies to Offline expansion.
The flow states the operator "pauses the Milvus database" (step 2) and "resumes the database" (step 5). For mode: Online, the volume is expanded without taking the pod down, so describing a pause/resume cycle is misleading. Please distinguish the flows:
- Offline: validate → pause → patch PVC → update spec → resume → mark successful.
- Online: validate → patch PVC (no pause) → mark successful.
Or reword step 2 to say the operator "validates the request and, for Offline mode, pauses the database."
🤖 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/milvus/volume-expansion/overview.md` around lines 50 - 56, The
volume expansion flow in the Milvus docs currently implies every
`MilvusOpsRequest` pauses and resumes the database, which is only true for
Offline mode. Update the overview steps to distinguish the `Offline` and
`Online` paths in the `MilvusOpsRequest` volume expansion flow: for Offline,
describe validate → pause → patch PVCs → update spec → resume → mark successful;
for Online, describe validate → patch PVCs without pausing → mark successful.
Use the existing step text in the overview section to reword step 2 and step 5
so they apply only to Offline expansion.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Adds user-facing documentation for KubeDB managed Milvus, covering both Standalone and Distributed topologies. Every guide embeds live output collected from a running cluster.
Pages added (
docs/guides/milvus/)/milvus/tlsmounts)milvus.yamlrotateAfter/activeFromand recommendation relationshipstreamingnodefor distributed)local-path→longhorn-customNotes
mixcoord/datanode/querynode/proxywhen onlystreamingnodeis specified, andstreamingnodeas the sole persistent-storage role for distributed storage operations.UpdateVersionpage transparently notes a test-cluster limitation: the2.6.9distributed instance's read-write health check did not stabilize on the single-node test cluster, so that live run is represented via the standalone capture; the operation completes on standalone and on a healthy distributed cluster.Summary by CodeRabbit