docs: add a Mooncake CacheRuntime sample for client-less cache systems - #6163
docs: add a Mooncake CacheRuntime sample for client-less cache systems#6163btxu-db wants to merge 1 commit into
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @btxu-db. Thanks for your PR. I'm waiting for a fluid-cloudnative member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Mooncake is a distributed KVCache store with no POSIX mount semantics: applications talk to the cache service through its own client library instead of a mount point. Its CacheRuntimeClass therefore declares only master and worker, and omits the client component. Add an end-to-end sample walking through that minimal setup, and document the client-less topology in the generic cache runtime integration guide, including the fact that Fluid still creates a Bound PVC/PV that application pods must not mount. Requires fluid-cloudnative#6157, without which the controller panics when a topology omits the client component. Signed-off-by: btxu-db <btxu-db@outlook.com>
938a186 to
cb28224
Compare
|
1 participant
Ⅰ. Describe what this PR does
Mooncake is a distributed KVCache store with no POSIX mount semantics: applications talk to the cache service through its own client library instead of reading and writing files through a mount point. Its
CacheRuntimeClasstherefore declares onlymasterandworkerundertopology, and omits theclientcomponent.This PR documents that client-less setup:
docs/{en,zh}/samples/cacheruntime/mooncake_cache_runtime.md— a new end-to-end sample: create theCacheRuntimeClass/Dataset/CacheRuntime, write and read data across pods and nodes through the Mooncake Python client, inspect the reported cache status, plus an FAQ entry.docs/{en,zh}/dev/generic_cache_runtime_integration.md— a new "cache systems without a client component" section describing when theclientcomponent may be omitted, and noting that Fluid still creates a Bound PVC/PV that application pods must not mount.docs/{en,zh}/TOC.md— table of contents entries.Docs only; no code changes.
Ⅱ. Does this pull request fix one issue?
NONE
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
No tests — this PR only adds documentation.
Ⅳ. Describe how to verify it
The sample was run end to end on a kind cluster: the
DatasetreachesBoundwith onlymasterandworkerdeclared, data written from one client pod is readable from a second client pod on a different node after the writer has exited, andreportSummary.shpopulatesstatus.cacheStates(cached: 4.00MiB,fileNum: 1). All command output shown in the document is copied from that run.Rendering: all relative links in the touched documents resolve to existing files, and the en/zh versions have identical heading structures.
Ⅴ. Special notes for reviews
topologyomits the client component, so the sample cannot be followed on current master. Please merge fix: avoid nil pointer dereference in CacheRuntime configmap builder #6157 first. The version note in the sample currently points readers at that PR; happy to replace it with a concrete release version once fix: avoid nil pointer dereference in CacheRuntime configmap builder #6157 lands.btxu/mooncake:v3, plus an Alibaba Cloud mirror for mainland China) that adds two scripts on top of the official Mooncake image:/custom-entrypoint.shand/reportSummary.sh. The document explains what both scripts do so readers can build an equivalent image themselves. If you would prefer the build context to live in this repository, I can follow up with a PR adding it (I have a Dockerfile alongside an e2e case for this client-less topology, which I intended to send separately).