docs: default RuntimeClass needs the resource admission labels

Aberta Para iniciantes
  • Algo errado?
#5,567 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
1/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
78/100
Tipo de issue
Documentação
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
docker, helm, kubernetes, rust
Domínio
documentation

Direção de pesquisa

Comece pelo comentário no arquivo de values do Helm chart sobre server.defaultRuntimeClassName e pela seção da documentação de configuração do gateway sobre admissão de recursos, que, segundo a issue, não mencionam o requisito de labels. Confirme no código do driver Kubernetes onde a RuntimeClass padrão é verificada contra os labels de admissão e observe que supervisor_runtime_class_name não é verificada. Está concluído quando os dois locais da documentação declararem o requisito de labels e a exceção, e a redação corresponder aos passos de reprodução.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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"
Linguagem predominante
Rust
Estrelas
21.5k
Forks
2.1k
Merge médio
2d 21h
PRs com merge (30d)
250

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NVIDIA/OpenShell

Todas as issues de NVIDIA/OpenShell

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.