feat: migrate AKernel deployment to Python YuanRong CLI

[mhsong1998-dot]

Summary

Migrate master, frontend, node, and standalone startup from the legacy Go launcher to the Python openYuanRong CLI. Preserve fixed deployment paths, role-specific logs, external sandboxd resource collection, distinct Pod/bridge addresses, DataSystem health and timeout settings, checkpoint storage, and YR_RRT_CONTROL_SOCKET_PATH.

Rebased onto main at 5be301df1333064571b8e4acbee21bc4535d05e6. The conflict resolution keeps the current YR_IMAGE_PROCESS_CONFIG startup contract and inherited-image-entrypoint support from main. The sandboxd gitlink points to inclusionAI/sandboxd#48 at bf42f63b2916afdcb6414374469df713c8209381.

Startup and storage behavior

• Launch openYuanRong with /opt/openyuanrong/bin/python /opt/openyuanrong/bin/yr ... start; master/frontend add --master and all roles keep blocking foreground supervision.
• Track foreground sandboxd with Type=simple. ExecStartPost=/usr/local/bin/sandboxd-network-ready waits until sandbox0 has an IPv4 address or reaches its bounded timeout, including the case where the interface does not exist yet.
• Create the DataSystem worker health directory before startup and restore cluster DataSystem timeouts.
• Configure rootfs and mount storage as native Nydus S3. Root-level S3 objects and nested prefixes are both supported; the chart clears the legacy OSS map when S3 is selected.

Validation

Local

• make SHELL=/bin/bash deploy-script-check
• python3 -m unittest discover -s builder/tests -v (6 passed)
• helm lint deploy/akernel/charts/core
• go test ./pkg/imagemanager/distillfs in the sandboxd submodule

Componentized CCE deployment

Validated head 7130e71b836455a031f64ead99e9f76768b01a5b in cn-north-4/akernel-cce, namespace akernel, Helm release akernel-core revision 52.

• Product image: swr.cn-north-4.myhuaweicloud.com/openyuanrong/cluster-all-in-one:pr19-7130e71
• Runtime digest on master, frontend, and all four nodes: sha256:d3f90dda928de51131b386acf6520b193817f3da6396308430b2cf012c36065e
• Master, frontend, four nodes, etcd, and Traefik are Ready. Both sandboxd.service and yuanrong.service are active on all four nodes; every node has a live sandbox0 IPv4 address.
• Process inspection confirms master/frontend and all nodes are running the Python yr CLI.
• The six DataSystem cluster records match the current master, frontend, and node Pod IPs.
• Root-level S3 rootfs/mount validation passed with a temporary in-cluster S3 fixture, which was deleted after testing.

Python examples

Ran all 14 files under sdk/python/examples using SDK client image swr.cn-north-4.myhuaweicloud.com/openyuanrong/akernel-sdk-client:pr19-7130e71 (sha256:3b636bbe50dc70dd8109f0990fa68e32eeb9b77c19037adaa83efaaa71db08ad).

• Passed: basic_usage, command_stdin, failover_reload, named_sandbox, network_policy, pty, reverse_tunnel, s3_rootfs_and_mounts, and storage_sandbox.
• custom_image, dockerfile_launch, and port_forwarding timed out while resolving their default public Docker Hub images. The same three examples passed without code changes when only their image addresses were switched to mirrored SWR images; all nine dockerfile_launch sections passed.
• gpu_sandbox reached scheduling and returned ERR_RESOURCE_NOT_ENOUGH because this cluster has no matching GPU card.
• sandbox_runtime passed the default and runsc paths, then reported that Kata is unsupported on these nodes.
• The first basic_usage attempt immediately after rollout hit the old frontend Pod IP once. A separate stable-state rerun passed the full create, command, file, background-process, and cleanup flow.

All temporary Jobs, Services, ConfigMaps, Secrets, and the S3 fixture were deleted after validation; all four node sandbox lists are empty.

[tianyuzhou95]

One remaining process issue before merge: the current commit body contains only the Signed-off-by trailer. The repository's AGENTS.md requires a Conventional Commit with a prose body explaining what changed and why, followed by the DCO sign-off. Please amend the commit message accordingly.

Also, GitHub currently reports no checks for this branch. The validation documented in the PR is extensive, but there is no automated status attached to the commit. Please ensure the expected CI checks are configured and passing before merge, or explicitly confirm that this repository does not currently provide PR checks.

[mhsong1998-dot]

Process items are addressed in current HEAD 1e30b39: the branch contains one lowercase Conventional Commit with a prose body, and its author, committer, and Signed-off-by trailer all match mhsong1998-dot. GitHub created CI run 32334113441 for this head, but currently marks it action_required, so a maintainer must approve the fork workflow before the checks can execute. The previously approved head passed all eight CI jobs.

[WenYuLuo]

Why do we need this file?

[mhsong1998-dot]

Kept. This file was added in response to the earlier reproducibility review (discussion_r3756876467): the core wheel metadata uses lower-bounded transitive dependencies, so pinning the complete Python 3.12 dependency closure prevents the same AKernel commit from resolving different versions over time. It is updated together with OPEN_YR_VERSION.

[WenYuLuo]

Seems to be a duplicate of line 10.

[mhsong1998-dot]

Updated in 7485d18. The entrypoint now consumes the role argument once, validates the resulting role once, and then exports AKERNEL_ROLE; the duplicate role-selection case is gone.

[WenYuLuo]

These two environments should not be set in this file.
Please move them to the yuanrong setup bash.

[mhsong1998-dot]

Updated in 7485d18. DEPLOY_PATH and YR_LOG_PATH are no longer set by akernel-entrypoint; the node/standalone YuanRong bootstrap remains the single place that supplies these defaults.

[WenYuLuo]

Seems it's a duplicate set in the Yuanrong startup script.

[mhsong1998-dot]

Updated in 7485d18 together with the node branch. The duplicate standalone assignments were removed, and the YuanRong bootstrap owns these defaults.

[WenYuLuo]

Not an elegant way. Any method to resolve this dependency? For example, can we set the yuanrong service to start after the sandboxd service? And the IP can be obtained from the ‘ip_range’ config.

[mhsong1998-dot]

Updated in 7485d18. sandboxd.service now has a bounded ExecStartPost readiness check for the live sandbox0 IPv4, and yuanrong.service explicitly Requires/starts After sandboxd. The YuanRong bootstrap therefore reads the address once instead of polling. The address is intentionally not derived from ip_range because the earlier review in discussion_r3734794038 required the actually assigned interface address as the source of truth.

[WenYuLuo]

Is it required for our deployment change? Why change the kata things?

[mhsong1998-dot]

Updated in 7485d18. The Kata license URL parameter and local download-timeout adjustment were unrelated build-network accommodations, so this block is restored to the current main-branch implementation.

[WenYuLuo]

Why we need to use venv?

[mhsong1998-dot]

The venv is retained because the Python CLI wheel now installs its complete runtime dependency set. It keeps those dependencies isolated from Ubuntu system Python and avoids mutating the externally managed system environment with --break-system-packages.

[WenYuLuo]

Those changes for what needs?

[mhsong1998-dot]

Retained as a security hardening required by the earlier review in discussion_r3756876315. The 0.10.1 wheel still logs the full component environment and persists component env_vars in session JSON. The exact grep checks make the build fail if an upstream source change causes either redaction patch to stop applying, rather than silently exposing values such as LITEBUS_DATA_KEY.

[WenYuLuo]

unnecessary

[mhsong1998-dot]

Removed in 7485d18. This implementation detail remains documented in the repository maintenance guidance and does not need to be part of the standalone user quick-start.