docs: default RuntimeClass needs the resource admission labels

Aperta Adatta ai principianti
#5,567 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
docker, helm, kubernetes, rust
Ambito
documentation

Direzione di ricerca

Inizia dal commento nel file dei values del chart Helm per server.defaultRuntimeClassName e dalla sezione della documentazione di configurazione del gateway sull'ammissione delle risorse, che secondo la issue non menzionano il requisito sulle label. Verifica nel codice del driver Kubernetes dove la RuntimeClass predefinita viene controllata rispetto alle label di ammissione, e annota che supervisor_runtime_class_name non viene controllata. È completato quando entrambe le posizioni della documentazione indicano il requisito sulle label e l'eccezione, e la formulazione corrisponde ai passaggi di riproduzione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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"
Lingua principale
Rust
Stelle
21.5k
Fork
2.1k
Merge medio
2g 21h
PR unite (30g)
250

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di NVIDIA/OpenShell

Tutte le issue di NVIDIA/OpenShell

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.