[Sabnaj-42]

A new Milvus has an empty etcd. On an object storage path that still holds another cluster's write-ahead logs, log ids restart, the old logs fence the writer, and writes time out while the status looks healthy. The operator never looked at S3, and the default path is files for every Milvus in a bucket.

Before the first pod starts, the operator counts the keys of the meta etcd. If there are none, a Job runs milvus-archiver storage-check against the rendered milvus.yaml.

• Path holds objects: the Milvus does not start. Condition ObjectStorageChecked=False, reason PathInUse, names the bucket and path. It rechecks every minute and starts by itself once the path is free.
• Etcd holds data (adoption): passes with no Job.
• The check cannot run: a warning, then the Milvus starts as before.
• Never runs for a provisioned Milvus or a restore. Annotation kubedb.com/milvus-skip-object-storage-check: "true" skips it.

WipeOut still never deletes object storage, the same as the official Milvus operator.

Stacked on milvus-inplace-adoption; merge that first.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[github-actions]

Visit the preview URL for this PR (updated for commit a9fcb61):

https://kubedb-v2-hugo--pr1088-milvus-object-storag-gv5zkd4v.web.app

_{(expires Thu, 12 Nov 2026 12:09:34 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 0f29ae8ae0bd54a99bf2b223b6833be47acd5943}