You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Triage (scanner): run 38180179764deploy-vllm-d failed at "Deploy with Helm" β the new pod kc-kubestellar-console-66b5bf45fc-fz8db is stuck Init:CreateContainerError until the Helm wait times out.
Root cause (from job diagnostics): SELinux relabel of the console data PVC fails β
This is not caused by commit 71d9147 β that commit (PR #24241, fsGroupChangePolicy: OnRootMismatch) addresses fsGroup chown, but this failure is kubelet's recursive SELinux relabel (lsetxattr), which fsGroupChangePolicy does not affect. The kubelet cannot set security.selinux xattrs on the existing console-*.db/.db-journal backup files on PV pvc-69c4a202-....
This needs cluster-side action on the fmaas vllm-d cluster (not a repo code fix):
run restorecon -R / fix ownership on the volume's files so lsetxattr succeeds, or
if the CSI backend doesn't support SELinux xattrs (e.g. NFS-backed), mount with a context= mount option at the StorageClass/PV level so kubelet skips per-file relabel, or
recreate the PVC (data loss limited to local db backups per the restore flow).
Flaky-vs-real verdict: real, infra/storage β every retry will hit the same relabel error until the volume is fixed. Deferring to the Build Sheriffs; no revert candidate exists since the breakage is independent of the source commit.
Update (scanner, 2026-10-12): two distinct failure causes now on main:
Persistent β deploy-vllm-d: kubelet SELinux relabel of the console data PVC fails (lsetxattr ... permission denied on existing console-*.db backups). Cluster-side storage fix still required (see earlier diagnosis).
Transient (new, run 38245463581) β build (linux/amd64) step "Build and push by digest" failed with public.ecr.aws/docker/library/alpine:3.24 ... 429 Too Many Requests β registry rate-limit, not a repo regression. Will clear on re-run; if it recurs, consider mirroring the base image to ghcr.io or adding registry auth.
No repo-side code change needed for either; leaving open until deploy-vllm-d passes.
Triage update (scanner): newest failure run 38245463581 (2026-10-12 11:58 UTC) is a different, transient cause β build (linux/amd64) step "Build and push by digest" failed pulling the base image:
public.ecr.aws/docker/library/alpine:3.24@sha256:294b683c...: 429 Too Many Requests
That is a registry rate-limit flake, not code; a re-run should pass the build job. The persistent deploy-vllm-d failure (SELinux lsetxattr ... permission denied on PV pvc-69c4a202-...) still requires cluster-side storage action as diagnosed above. No repo code fix applicable for either.
Triage update (scanner, 2026-10-12): latest failure run 38245463581 failed at a DIFFERENT step than the ongoing incident β the build (linux/amd64) job hit a transient registry rate-limit pulling the base image:
public.ecr.aws/docker/library/alpine:3.24 ... 429 Too Many Requests
That is a one-off infra blip, not the SELinux PVC relabel issue tracked above (which still blocks deploy-vllm-d on every run that reaches it). No repo code fix applies to either failure mode; the PVC relabel still needs cluster-side action on the fmaas vllm-d cluster.
Activity
hivecommons-hive commentedon Oct 11, 2026
Triage (scanner): run 38180179764
deploy-vllm-dfailed at "Deploy with Helm" β the new podkc-kubestellar-console-66b5bf45fc-fz8dbis stuckInit:CreateContainerErroruntil the Helm wait times out.Root cause (from job diagnostics): SELinux relabel of the console data PVC fails β
This is not caused by commit 71d9147 β that commit (PR #24241,
fsGroupChangePolicy: OnRootMismatch) addresses fsGroup chown, but this failure is kubelet's recursive SELinux relabel (lsetxattr), whichfsGroupChangePolicydoes not affect. The kubelet cannot setsecurity.selinuxxattrs on the existingconsole-*.db/.db-journalbackup files on PVpvc-69c4a202-....This needs cluster-side action on the fmaas vllm-d cluster (not a repo code fix):
restorecon -R/ fix ownership on the volume's files so lsetxattr succeeds, orFlaky-vs-real verdict: real, infra/storage β every retry will hit the same relabel error until the volume is fixed. Deferring to the Build Sheriffs; no revert candidate exists since the breakage is independent of the source commit.
π Hive Agent:
scanner| Instance:hosted-kubestellar-console-4vkt| SHA:4195ab9β hive: agent=scanner backend=copilot model=claude-fable-5 copilot=1.0.88
github-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.deploy-vllm-dgithub-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.deploy-vllm-dgithub-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.deploy-vllm-dgithub-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.deploy-vllm-dgithub-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.build (linux/amd64, ubuntu-24.04, amd64)hivecommons-hive commentedon Oct 12, 2026
Update (scanner, 2026-10-12): two distinct failure causes now on
main:deploy-vllm-d: kubelet SELinux relabel of the console data PVC fails (lsetxattr ... permission deniedon existingconsole-*.dbbackups). Cluster-side storage fix still required (see earlier diagnosis).build (linux/amd64)step "Build and push by digest" failed withpublic.ecr.aws/docker/library/alpine:3.24 ... 429 Too Many Requestsβ registry rate-limit, not a repo regression. Will clear on re-run; if it recurs, consider mirroring the base image to ghcr.io or adding registry auth.No repo-side code change needed for either; leaving open until deploy-vllm-d passes.
π Hive Agent:
scanner| Instance:hosted-kubestellar-console-4vkt| SHA:befb46dβ hive: agent=scanner backend=copilot model=claude-fable-5 copilot=1.0.88
hivecommons-hive commentedon Oct 12, 2026
Triage update (scanner): newest failure run 38245463581 (2026-10-12 11:58 UTC) is a different, transient cause β
build (linux/amd64)step "Build and push by digest" failed pulling the base image:That is a registry rate-limit flake, not code; a re-run should pass the build job. The persistent
deploy-vllm-dfailure (SELinuxlsetxattr ... permission deniedon PVpvc-69c4a202-...) still requires cluster-side storage action as diagnosed above. No repo code fix applicable for either.π Hive Agent:
scanner| Instance:hosted-kubestellar-console-4vkt| SHA:3c4a38fβ hive: agent=scanner backend=copilot model=claude-fable-5 copilot=1.0.88
hivecommons-hive commentedon Oct 12, 2026
Triage update (scanner, 2026-10-12): latest failure run 38245463581 failed at a DIFFERENT step than the ongoing incident β the
build (linux/amd64)job hit a transient registry rate-limit pulling the base image:That is a one-off infra blip, not the SELinux PVC relabel issue tracked above (which still blocks
deploy-vllm-don every run that reaches it). No repo code fix applies to either failure mode; the PVC relabel still needs cluster-side action on the fmaas vllm-d cluster.π Hive Agent:
scanner| Instance:hosted-kubestellar-console-4vkt| SHA:725488cβ hive: agent=scanner backend=copilot model=claude-fable-5 copilot=1.0.88
github-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.deploy-vllm-dgithub-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.deploy-vllm-dgithub-actions commentedon Oct 12, 2026
Still red β
Build and Deploy KCfailed again onmain.build (linux/amd64, ubuntu-24.04, amd64)hivecommons-hive commentedon Oct 13, 2026
Fixed by #24268 (merged 147eebe). Closing. Reply /reopen if the problem persists.