docs: default RuntimeClass needs the resource admission labels

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#5,567 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
1/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
78/100
Issue-Typ
Dokumentation
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
docker, helm, kubernetes, rust
Bereich
documentation

Rechercherichtung

Beginne mit dem Kommentar in den Helm-Chart-Values für server.defaultRuntimeClassName und mit dem Abschnitt zur Ressourcenzulassung in der Dokumentation zur Gateway-Konfiguration. Laut Issue fehlt in beiden Stellen der Hinweis auf die Label-Anforderung. Prüfe im Code des Kubernetes-Treibers, wo die Default-RuntimeClass gegen die Admission-Labels geprüft wird, und notiere, dass supervisor_runtime_class_name nicht geprüft wird. Fertig ist es, wenn beide Dokumentationsstellen die Label-Anforderung und die Ausnahme benennen und der Wortlaut zu den Reproduktionsschritten passt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

state:triage-needed
User Story

I use OpenShell's Kubernetes driver and I am running its sandboxes under Kata Containers for VM-level isolation. I directly hit this while setting default_runtime_class_name to a Kata RuntimeClass on a test cluster. This affects anyone who sets a default RuntimeClass for all sandboxes.

Problem Statement

With server.defaultRuntimeClassName (default_runtime_class_name) set to the name of a RuntimeClass that has no labels, every openshell sandbox create fails with external resource not admitted by required labels. The docs for defaultRuntimeClassName and the resource admission section on the gateway configuration page do not say that the default RuntimeClass has to carry the admission label. The admission section only describes resources that a caller selects. supervisor_runtime_class_name is not subject to the same check, which is also not documented.

Impact / Why This Matters

Operators who configure a default RuntimeClass get a failing sandbox create and nothing in the chart values or the configuration docs points at the cause. The workaround is to find the label requirement in the admission section and label the RuntimeClass (openshell.ai/sandbox-attachable=true by default). Until then no sandbox can be created on that gateway.

Acceptance Criteria
  • The documentation next to defaultRuntimeClassName / default_runtime_class_name states that the RuntimeClass needs the resource admission labels.
  • The resource admission section states that the check covers the default RuntimeClass and that supervisor_runtime_class_name is not checked.
Reproduction Steps
  1. Create a RuntimeClass with no labels, for example one named my-runtime whose handler exists on the nodes.
  2. Install the chart with server.defaultRuntimeClassName=my-runtime.
  3. Run openshell sandbox create --name t1 --no-tty -- true.
  4. The command fails with RuntimeClass 'my-runtime': external resource not admitted by required labels.
  5. Run kubectl label runtimeclass my-runtime openshell.ai/sandbox-attachable=true and repeat step 3. It succeeds.
Suggested UX (if applicable)

Documentation only. No behavior change is requested.

Environment
  • OpenShell: gateway 0.1.9-dev.30+g2e5589b21 (built from main at 2e5589b21), Kubernetes driver, Helm chart from the same commit
  • OS: Fedora, kind v1.36 test cluster
  • Runtime: Kata Containers 4.3.1 (QEMU), RuntimeClass handler kata-qemu
  • The check was run with an AI coding agent (opencode) under my direction. I have not hit this in production.
Logs
Error:   × code: 'The system is not in a state required for the operation's
  │ execution', message: "RuntimeClass 'kata-qemu-unl': external resource not
  │ admitted by required labels"
Vorherrschende Sprache
Rust
Sterne
21.5k
Forks
2.1k
Ø Merge
2 T. 21 Std.
Gemergte PRs (30 T.)
250

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NVIDIA/OpenShell

Alle Issues in NVIDIA/OpenShell

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.