feat: migrate AKernel deployment to Python YuanRong CLI - #19
feat: migrate AKernel deployment to Python YuanRong CLI#19mhsong1998-dot wants to merge 1 commit into
Conversation
b7de90a to
7e5c006
Compare
7e5c006 to
6a7e84d
Compare
|
One remaining process issue before merge: the current commit body contains only the 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. |
3d195f7 to
317abec
Compare
ae77634 to
1e30b39
Compare
|
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. |
bfa5b8b to
4d55ac6
Compare
4d55ac6 to
1852878
Compare
| @@ -0,0 +1,30 @@ | |||
| # Runtime dependency lock for openyuanrong-core 0.10.1 on Python 3.12. | |||
There was a problem hiding this comment.
Why do we need this file?
There was a problem hiding this comment.
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.
| fi | ||
| fi | ||
|
|
||
| case "${role}" in |
There was a problem hiding this comment.
Seems to be a duplicate of line 10.
There was a problem hiding this comment.
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.
| ;; | ||
| node) | ||
| export DEPLOY_PATH="${DEPLOY_PATH:-/home/yuanrong}" | ||
| export YR_LOG_PATH="${YR_LOG_PATH:-${DEPLOY_PATH}/logs}" |
There was a problem hiding this comment.
These two environments should not be set in this file.
Please move them to the yuanrong setup bash.
There was a problem hiding this comment.
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.
| ;; | ||
| standalone) | ||
| export DEPLOY_PATH="${DEPLOY_PATH:-/home/yuanrong}" | ||
| export YR_LOG_PATH="${YR_LOG_PATH:-${DEPLOY_PATH}/logs}" |
There was a problem hiding this comment.
Seems it's a duplicate set in the Yuanrong startup script.
There was a problem hiding this comment.
Updated in 7485d18 together with the node branch. The duplicate standalone assignments were removed, and the YuanRong bootstrap owns these defaults.
| sleep 1 | ||
| done | ||
|
|
||
| echo "timed out after 60s waiting for sandbox0 to have an IPv4 address" >&2 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
| ARG FIRECRACKER_RELEASE | ||
| ARG FIRECRACKER_AMD64_SHA256 | ||
| ARG FIRECRACKER_AMD64_URL | ||
| ARG KATA_LICENSE_URL=https://raw.githubusercontent.com/kata-containers/kata-containers/${KATA_RELEASE}/LICENSE |
There was a problem hiding this comment.
Is it required for our deployment change? Why change the kata things?
There was a problem hiding this comment.
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.
| echo "${wheel_sha} ${wheel}" | sha256sum -c -; \ | ||
| python3 -m pip install \ | ||
| --break-system-packages \ | ||
| python3 -m venv /opt/openyuanrong; \ |
There was a problem hiding this comment.
Why we need to use venv?
There was a problem hiding this comment.
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.
| sed -i 's/"env_vars": comp.env_vars,/"env_vars": {},/' "${launcher_py}"; \ | ||
| grep -Fq '"env_vars": {},' "${launcher_py}"; \ | ||
| ! grep -Fq '"env_vars": comp.env_vars,' "${launcher_py}"; \ | ||
| test -x /opt/openyuanrong/bin/yr; \ |
There was a problem hiding this comment.
Those changes for what needs?
There was a problem hiding this comment.
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.
| default) | ||
| - Print the Traefik container IP to use as `AKERNEL_SERVER_ADDRESS` | ||
|
|
||
| The openYuanRong bootstrap waits for `sandbox0` and uses the IPv4 address |
There was a problem hiding this comment.
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.
Replace the legacy Go launcher with the openYuanRong 0.10.1 Python CLI while preserving AKernel role behavior, fixed deployment paths, observability paths, and cloud deployment settings. Order YuanRong after sandboxd network readiness so local_ip still comes from the live sandbox0 interface without polling in the YuanRong bootstrap. Remove duplicate entrypoint defaults and keep unrelated validation fixes intact. Signed-off-by: mhsong1998-dot <258010372+mhsong1998-dot@users.noreply.github.com>
1852878 to
7485d18
Compare
3 participants
Summary
0.10.1, including the core wheel checksums, RRT checksum, Python SDK/sandbox dependency pins, dependency constraints, and thesrc/yuanronggitlink.Runtime paths
DEPLOY_PATH=/home/yuanrong/master,YR_LOG_PATH=/home/yuanrong/master/logDEPLOY_PATH=/home/yuanrong,YR_LOG_PATH=/home/yuanrong/logsYR_LOG_PATH.--log-dir-prefixand does not generate timestamps.Review fixes
node.sandboxIPRange.values.host_ip, wait forsandbox0IPv4 readiness, and use its bridge address asvalues.local_ipfor the dual-address FunctionProxy path.Validation
Current HEAD:
1852878cb054abc569db5a9f2a888073101ccb73, one author-signed Conventional Commit.linux/amd64runtime imageakernel-ci/runtime:pr19-1852878-0.10.1-amd64.linux/amd64all-in-one imageakernel-ci/all-in-one:pr19-1852878-0.10.1-amd64(sha256:2edbe7881be46ecffd3cdc9b9ecfedbadc1b16865471ff2b35cd48f6bb2c14bd).openyuanrong-core==0.10.1;yr --help, OTel Collector, RRT rootfs, and both wheel safety patches passed smoke checks.grpc_listen_port=22773,component_grpc_port=22774, Podhost_ip, and distinct sandbox bridgelocal_ip.The local build used exact OBS 0.10.1 artifacts through temporary build arguments because public GitHub/PyPI publication was not yet complete when validated. No credential, test/plan file, temporary download URL, mirror, or trusted-host setting is committed.