test: add an e2e case for a client-less CacheRuntime topology - #6164
test: add an e2e case for a client-less CacheRuntime topology#6164btxu-db wants to merge 1 commit into
Conversation
Mooncake has no POSIX mount semantics, so its CacheRuntimeClass declares only master and worker. No existing e2e case covers that shape: curvine ships a client component, so the client-less path through the controller is untested. The case pins down the behaviour that path is expected to have: - the controller does not panic and the Dataset reaches Bound with the client component omitted (a regression guard for the nil pointer dereference fixed in fluid-cloudnative#6157); - no client DaemonSet or client pods are created, and status.client.phase stays empty; - the ReportSummary script populates status.cacheStates, and cached reflects data written through the cache system's own client; - the Dataset PVC reaches Bound but cannot be mounted by application pods, which is what the docs' FAQ describes. The image is built in-repo from test/gha-e2e/mooncake/image rather than pulled from an external registry, for the same reason as the jindo oss-emulator: e2e runs on every PR, and the two scripts Fluid invokes inside the image have to be reviewable. Signed-off-by: btxu-db <btxu-db@outlook.com>
|
[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. |
|
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| restartPolicy: Never | ||
| automountServiceAccountToken: false | ||
| containers: | ||
| - name: app |
| restartPolicy: Never | ||
| automountServiceAccountToken: false | ||
| containers: | ||
| - name: app |
| jq \ | ||
| && rm -rf /var/lib/apt/lists/* | ||
|
|
||
| RUN pip install --no-cache-dir \ |
| RUN pip install --no-cache-dir \ | ||
| mooncake-transfer-engine-non-cuda==0.3.12.post1 \ | ||
| nvidia-cuda-runtime-cu12 |
| # python:3.12.13-slim — slim is required: the full variant carries an extra | ||
| # ~700MB build toolchain, growing the image from ~470MB to ~1.9GB, and e2e also | ||
| # has to kind-load it onto the node and keep a second copy there. | ||
| FROM python:3.12.13-slim@sha256:229a2c5bfa27522db7815ea81f9bed70af17ccb9de9fc7ad142b1877b5830d36 |
| exec mooncake_client \ | ||
| --host="$WORKER_HOST" \ | ||
| --port=50052 \ | ||
| --global_segment_size="$SEGMENT_SIZE" \ | ||
| --master_server_address="$MASTER_ADDR" \ | ||
| --metadata_server="$METADATA_ADDR" \ |
|
Closing this — opened by mistake on my side, not intended for review. Sorry for the noise. |
2 participants
Ⅰ. Describe what this PR does
Adds an e2e case covering a client-less CacheRuntime topology — a
CacheRuntimeClasswhosetopologydeclares onlymasterandworker, with noclientcomponent.No existing case covers that shape: the curvine case ships a client component, so the client-less path through
cacheruntime-controlleris currently untested. Mooncake is used as the concrete cache system because it genuinely has no POSIX mount semantics — applications talk to the cache service through its own client library rather than a mount point.test/gha-e2e/mooncake/— the case itself (CacheRuntimeClass/Dataset/CacheRuntimemanifests, a read/write Job, a negative-case pod, andtest.sh).test/gha-e2e/mooncake/image/— the image build context: a Dockerfile on top ofpython:3.12.13-slimplus the two scripts Fluid invokes (custom-entrypoint.sh,reportSummary.sh)..github/scripts/build-all-images.sh— build and kind-load${IMG_REPO}/mooncake:e2e..github/scripts/gha-e2e.sh— run the new case aftercurvine_e2e.Ⅱ. 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.
This PR is itself an e2e case. It asserts:
panic:/nil pointer dereferencewhile waiting, so a regression reports its root cause instead of just a Bound timeout.cacheruntime.status.client.phasestays empty. (status.clientdoes exist as{"phase":""}andspec.clientis filled in by CRD defaults, so the empty phase is the actual criterion.)status.cacheStatesgets populated,ufsTotal == cacheCapacityfor this UFS-less system, andcached/fileNumreflect data actually written.volumes/volumeMountsanywhere in the pod.FailedMountevent mentioning the missing FUSE mount point. This is the behaviour the docs' FAQ describes, pinned down so it cannot go stale silently.On failure the case dumps controller logs,
describeoutput for the CacheRuntime / Dataset / stuck pod, job logs and namespace events.Ⅳ. Describe how to verify it
against a kind cluster with Fluid deployed and
fluidcloudnative/mooncake:e2eloaded, which is what.github/scripts/build-all-images.shand.github/scripts/gha-e2e.shwire up for CI. The case was run end to end locally on kind.Ⅴ. Special notes for reviews
wait_dataset_bound— which is precisely the regression it guards. Please merge fix: avoid nil pointer dereference in CacheRuntime configmap builder #6157 first.test/gha-e2e/mooncake/image/here is it. Happy to follow up on docs: add a Mooncake CacheRuntime sample for client-less cache systems #6163 with a docs change pointing readers at this directory once both land.test/gha-e2e/jindo/oss-emulator: e2e runs on every PR, an external image going away turns the pipeline red, and the two scripts Fluid invokes need to be reviewable. The only external dependency is Mooncake's official PyPI package.python:3.12.13-slimis pinned by digest; the non-slim variant would grow the image from ~470MB to ~1.9GB, which e2e then has to kind-load as well.test/gha-e2e/mooncake/cacheruntimeclass.yamldeliberately declares noresourceson its containers, and says why in a comment: when the CacheRuntimeClass template sets resources but the CacheRuntime does not,syncRuntimeSpecpasses the zero value toupdateResources, which overwrites the template's resources with an empty value — silently dropping them and triggering an ASTS rollout that can leave the Dataset stuck inFailed. That looks like a genuine bug; I can open a separate issue with the details if that would be useful.