Please consider publishing a new all-in-one Helm chart, the official chart artifact has been stuck on 0.1.0 (2026-03-05) for 5 months

[y4ney]

Why do you need it?

Users installing OpenSandbox via the officially published all-in-one chart can only get 0.1.0, released 2026-03-05, which is five months ago. Below is the full timeline and its impact.

Release timeline

2026-03-05 16:22 +0800: OpenSandbox chart 0.1.0 was published (the tag was created at 15:02 +0800 the same day). It ships server image v0.1.4 and controller image v0.1.0. Note that although the controller image tag below is empty, the helper takes the appVersion (0.1.0) and prepends the v prefix to build the controller image tag.

$ curl -sL https://github.com/opensandbox-group/OpenSandbox/releases/download/helm/opensandbox/0.1.0/opensandbox-0.1.0.tgz | tar xzO 'opensandbox/charts/*/values.yaml' | grep -E 'repository:|tag:'
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/controller
    tag: ""
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/server
    tag: "v0.1.4"
      repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/ingress
      tag: "v1.0.2"

{{/*
Controller image with automatic version prefix handling.
Prepends 'v' to semantic version tags (e.g., 0.0.1 -> v0.0.1) but preserves
special tags like 'latest', 'dev', 'main', etc. as-is.
*/}}
{{- define "opensandbox.controllerImage" -}}
{{- $tag := .Values.controller.image.tag | default .Chart.AppVersion }}
{{- $finalTag := $tag }}
{{- if and (not (hasPrefix "v" $tag)) (regexMatch "^[0-9]+\.[0-9]+\.[0-9]+" $tag) }}
{{- $finalTag = printf "v%s" $tag }}
{{- end }}
{{- printf "%s:%s" .Values.controller.image.repository $finalTag }}
{{- end }}

2026-05-15 14:32 +0800: OpenSandbox chart 0.2.0 was published (tag created at 14:30 +0800 the same day). Based on source analysis it pins server image v0.1.13 and controller image v0.2.0:

$ for f in opensandbox-server opensandbox-controller; do echo "=== $f ==="; curl -sL "https://raw.githubusercontent.com/opensandbox-group/OpenSandbox/helm/opensandbox/0.2.0/kubernetes/charts/$f/values.yaml" | grep -E 'repository:|tag:|_image|image ='; curl -sL "https://raw.githubusercontent.com/opensandbox-group/OpenSandbox/helm/opensandbox/0.2.0/kubernetes/charts/$f/Chart.yaml" | grep appVersion; done
=== opensandbox-server ===
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/server
    tag: "v0.1.13"
      repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/ingress
      tag: "v1.0.7"
  execd_image = "sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/execd:v1.0.16"
  image = "sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/egress:v1.0.11"
appVersion: "0.1.0"
=== opensandbox-controller ===
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/controller
    tag: ""
appVersion: "0.2.0"

However, the 0.2.0 publish failed because Chart.lock was out of date. Note that the run logs are no longer viewable in the web UI due to retention limits, but they are still retrievable via the CLI: gh run view 25904053319 -R opensandbox-group/OpenSandbox --log-failed

publish UNKNOWN STEP    2026-05-15T06:33:30.9751596Z Building dependencies for all-in-one chart...
publish UNKNOWN STEP    2026-05-15T06:33:31.0085932Z Error: the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml). Please update the dependencies with 'helm dependency update'
publish UNKNOWN STEP    2026-05-15T06:33:31.0104399Z ##[error]Process completed with exit code 1.

Although Chart.lock was fixed the same day (#896), the workflow was never re-triggered to republish chart 0.2.0. Worse, the asset attached to that release is actually the standalone controller chart produced by the sibling tag helm/opensandbox-controller/0.2.0, not the all-in-one package.

2026-07-20 18:17 +0800: the new server v0.2.2 was released, and the all-in-one chart on main (commit 5a335c2d, "release opensandbox 0.2.2 (server v0.2.2 + controller v0.2.0)") already bundles it, with Chart.lock in sync, so it is ready to publish at any time.

Impact on users

• helm install from the official all-in-one chart can only get 0.1.0 (server v0.1.4, eight minor versions behind; execd v1.0.6 vs v1.0.21 on main; no egress support at all vs v1.1.5 on main).
• Many fixes merged to main were never delivered to all-in-one users, e.g. #1336 (Pool CRD missing scaleStrategy/updateStrategy/recycleStrategy), #1238 (ingress-gateway env vars, blocking OTLP), #1299 (--image-committer-pull-secret, required for private registries).
• Chart/image version skew has happened before: #758 (chart version not bumped after a server release) and #855 (controller crash flag provided but not defined: -kube-client-qps, where the chart passed a flag the image did not know) share the same root cause as this incident.

How could it be?

Three asks for the maintainers:

1. Publish a new all-in-one chart soon (0.2.2 is suggested, corresponding to 5a335c2d on main where Chart.lock is in sync). Republishing 0.2.0 is not worth it: the tag points at an old commit where server is still v0.1.13, and moving an already-published tag is bad practice. Either pushing a tag or a workflow_dispatch works, and I have verified the whole pipeline on my fork (see below).
2. Fix the --containerd-socket-path crash before publishing: the current chart on main passes --containerd-socket-path to the controller, but the latest controller image v0.2.0 (no release since 2026-05-15) does not include that flag (#859 was merged after the v0.2.0 tag), so a default install crash-loops with flag provided but not defined: -containerd-socket-path. Since the binary's built-in default (/var/run/containerd/containerd.sock) is correct on standard nodes, consider defaulting controller.snapshot.containerdSocketPath to "" in chart values (the template already omits the flag for empty values), so a default install works with both old and new controller images.
3. Add a mechanism to prevent recurrence: make chart publishing part of the release process (bump and publish the chart with every server/controller release), or add a CI check that fails when Chart.yaml and Chart.lock are out of sync for the tag being published, avoiding another "release with a wrong asset unnoticed for three months".

Other related information

Feasibility check: I published 0.2.1 on my fork in two steps

I forked the repo, and based on main right after PR #1420 was merged (2026-08-11 18:21:44 +0800), published a new OpenSandbox 0.2.1 chart (Release / workflow run). Only two steps were needed:

1. Bump the all-in-one chart version to 0.2.1. Since 0.2.0 was already taken by the (failed) release, I picked 0.2.1; I don't know the project's chart versioning conventions, so this naming is arbitrary.
2. Push tag helm/opensandbox/0.2.1 and trigger the Publish Helm Chart workflow. It ships server v0.2.2 and controller v0.2.0:

$ curl -sL https://github.com/y4ney/OpenSandbox/releases/download/helm%2Fopensandbox%2F0.2.1/opensandbox-0.2.1.tgz | tar xzO 'opensandbox/charts/*/values.yaml' | grep -E 'repository:|tag:'
  repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/nodeagent
  tag: ""
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/server
    tag: "v0.2.2"
      repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/ingress
      tag: "v1.0.10"
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/controller
    tag: ""

Related issues

• #1217, the existing request to publish charts as releases

中文版（点开折叠）

为什么需要它？

通过官方发布的 all-in-one Chart 安装 OpenSandbox 的用户，目前只能安装到 2026-03-05 发布的 0.1.0，距今已 5 个月。以下是完整的时间线及其影响。

发布时间线

2026-03-05 16:22 +0800：发布了 OpenSandbox 0.1.0 Chart（tag 打于当天 15:02 +0800），其中 server 镜像 tag 为 v0.1.4，controller 镜像 tag 为 v0.1.0。请注意，下述 controller 镜像 tag 虽然为空，但 helper 会取 appVersion 的值（0.1.0）并补上 v 前缀构建 controller 镜像的 tag。

$ curl -sL https://github.com/opensandbox-group/OpenSandbox/releases/download/helm/opensandbox/0.1.0/opensandbox-0.1.0.tgz | tar xzO 'opensandbox/charts/*/values.yaml' | grep -E 'repository:|tag:'
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/controller
    tag: ""
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/server
    tag: "v0.1.4"
      repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/ingress
      tag: "v1.0.2"

{{/*
Controller image with automatic version prefix handling.
Prepends 'v' to semantic version tags (e.g., 0.0.1 -> v0.0.1) but preserves
special tags like 'latest', 'dev', 'main', etc. as-is.
*/}}
{{- define "opensandbox.controllerImage" -}}
{{- $tag := .Values.controller.image.tag | default .Chart.AppVersion }}
{{- $finalTag := $tag }}
{{- if and (not (hasPrefix "v" $tag)) (regexMatch "^[0-9]+\.[0-9]+\.[0-9]+" $tag) }}
{{- $finalTag = printf "v%s" $tag }}
{{- end }}
{{- printf "%s:%s" .Values.controller.image.repository $finalTag }}
{{- end }}

2026-05-15 14:32 +0800：发布了 OpenSandbox 0.2.0 chart（tag 打于当天 14:30 +0800），根据源码分析 server 镜像 tag 为 v0.1.13，controller 镜像 tag 为 v0.2.0：

$ for f in opensandbox-server opensandbox-controller; do echo "=== $f ==="; curl -sL "https://raw.githubusercontent.com/opensandbox-group/OpenSandbox/helm/opensandbox/0.2.0/kubernetes/charts/$f/values.yaml" | grep -E 'repository:|tag:|_image|image ='; curl -sL "https://raw.githubusercontent.com/opensandbox-group/OpenSandbox/helm/opensandbox/0.2.0/kubernetes/charts/$f/Chart.yaml" | grep appVersion; done
=== opensandbox-server ===
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/server
    tag: "v0.1.13"
      repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/ingress
      tag: "v1.0.7"
  execd_image = "sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/execd:v1.0.16"
  image = "sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/egress:v1.0.11"
appVersion: "0.1.0"
=== opensandbox-controller ===
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/controller
    tag: ""
appVersion: "0.2.0"

但由于 Chart.lock 没更新，OpenSandbox 0.2.0 Chart 发布失败。请注意，由于时间太久，UI 已经无法看到日志了，但仍然可以通过 CLI 命令 gh run view 25904053319 -R opensandbox-group/OpenSandbox --log-failed 进行查看：

publish UNKNOWN STEP    2026-05-15T06:33:30.9751596Z Building dependencies for all-in-one chart...
publish UNKNOWN STEP    2026-05-15T06:33:31.0085932Z Error: the lock file (Chart.lock) is out of sync with the dependencies file (Chart.yaml). Please update the dependencies with 'helm dependency update'
publish UNKNOWN STEP    2026-05-15T06:33:31.0104399Z ##[error]Process completed with exit code 1.

虽然当天有人提交更新了 Chart.lock 的内容（#896），但之后再没有触发过工作流重新发布 OpenSandbox 0.2.0 Chart，且该 Release 页面挂的附件实际上是同批 tag helm/opensandbox-controller/0.2.0 产出的 controller 单 chart 包，而非 all-in-one 包。

2026-07-20 18:17 +0800：新的 server v0.2.2 已发布，而 main 分支上的 all-in-one chart（commit 5a335c2d，提交信息 release opensandbox 0.2.2 (server v0.2.2 + controller v0.2.0)）也已捆绑该镜像，Chart.lock 处于同步状态，随时可以发布。

对用户的影响

• helm install 拉取官方发布的 all-in-one Chart 只能装到 0.1.0（server v0.1.4，落后 8 个 minor 版本；execd v1.0.6 → main 上已是 v1.0.21；egress 能力完全缺失 → main 已有 v1.1.5）。
• 大量已修复并合入 main 的问题从未通过 chart 交付给 all-in-one 用户，例如 #1336（Pool CRD 缺 scaleStrategy/updateStrategy/recycleStrategy）、#1238（ingress-gateway 无法配置 env，阻断 OTLP）、#1299（私有 registry 场景必需的 --image-committer-pull-secret）等。
• "chart 与镜像版本错配"已不是第一次发生：#758（server 发版后 chart 版本没跟上）、#855（controller 崩溃 flag provided but not defined: -kube-client-qps，chart 传了镜像不认识的 flag）都与本次同源。

希望怎么做？

向维护团队提出三点请求：

1. 尽快发布新版 all-in-one Chart（建议直接 0.2.2，对应 main 上 5a335c2d，Chart.lock 已同步）。重发 0.2.0 意义不大：tag 指向的旧 commit 里 server 还停留在 v0.1.13，且移动已发布的 tag 也不符合惯例。推 tag 或 workflow_dispatch 均可，我在 fork 上已验证整条流水线是通的（见下文）。
2. 发布前请一并处理 --containerd-socket-path 崩溃：当前 main 的 chart 会给 controller 传 --containerd-socket-path，但最新的 controller 镜像 v0.2.0（2026-05-15 后未再发版）不包含该参数（#859 在 v0.2.0 tag 之后才合入），默认安装会 CrashLoop：flag provided but not defined: -containerd-socket-path。由于二进制内置默认值 /var/run/containerd/containerd.sock 在标准节点上就是正确的，建议先把 chart values 里 controller.snapshot.containerdSocketPath 默认值改为 ""（模板对空值已会省略该参数），使默认安装在新旧 controller 镜像下都能工作。
3. 建立机制避免复发：把 chart 发布纳入发版流程（每个 server/controller 发版都 bump chart 并发布），或在 CI 中加入校验：被发布 tag 的 Chart.yaml 与 Chart.lock 不同步时直接失败，避免再出现"Release 挂错附件、三个月无人发现"的情况。

其他相关信息

可行性验证：我在 fork 上用两步发布了 0.2.1

我已经 fork 该仓库，并基于 PR #1420 合入 main（2026-08-11 18:21:44 +0800）之后的状态，发布了新的 OpenSandbox 0.2.1 Chart（Release / Workflow 运行记录）。这个过程仅做了两件事：

1. 修改了 all-in-one Chart 的 version 为 0.2.1。由于 0.2.0 已被（失败的）Release 占用，因此版本号取 0.2.1；不了解项目官方的 chart 版本管理规范，此命名仅是我的随意选择。
2. 推送 tag helm/opensandbox/0.2.1 并触发 Publish Helm Chart 工作流。其中 server 镜像 tag 为 v0.2.2，controller 镜像 tag 为 v0.2.0：

$ curl -sL https://github.com/y4ney/OpenSandbox/releases/download/helm%2Fopensandbox%2F0.2.1/opensandbox-0.2.1.tgz | tar xzO 'opensandbox/charts/*/values.yaml' | grep -E 'repository:|tag:'
  repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/nodeagent
  tag: ""
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/server
    tag: "v0.2.2"
      repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/ingress
      tag: "v1.0.10"
    repository: sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/controller
    tag: ""

相关 issue

• #1217，要求将 chart 作为 release 发布的既有诉求