OpenShell gateway on WSL2/Docker Desktop installs but openshell-0 stays in ContainerCreating because TLS secrets are never created

[Guillosanti]

Environment

• Windows 10 Home
• WSL2
• Ubuntu 24.04.1 LTS
• Docker Desktop with WSL integration enabled
• Docker Engine config includes "default-cgroupns-mode": "host"
• Node v22.22.1
• npm 10.9.4
• NVIDIA GeForce RTX 3080 Laptop GPU, 16 GB VRAM

Install path

• git clone https://github.com/NVIDIA/NemoClaw
• cd NemoClaw
• sudo npm install -g .
• nemoclaw onboard

Observed behavior

• Preflight checks pass
• OpenShell CLI installs
• NVIDIA GPU is detected
• OpenShell gateway container starts
• openshell namespace is created
• Helm release reports STATUS: deployed
• PVC is created and bound
• Service openshell is created
• Pod openshell-0 stays in ContainerCreating

Evidence

kubectl -n openshell get secrets only shows:

• sh.helm.release.v1.openshell.v1

Required secrets are missing:

• openshell-server-tls
• openshell-server-client-ca

kubectl -n openshell describe pod openshell-0 shows repeated:

• FailedMount: secret "openshell-server-tls" not found
• FailedMount: secret "openshell-server-client-ca" not found

helm -n openshell get manifest openshell references:

• secretName: openshell-server-tls
• secretName: openshell-server-client-ca

But no Secret / Issuer / Certificate resources appear to be created.

Question

Is this a known WSL2/OpenShell chart issue, or is an extra TLS bootstrap step currently missing from the docs?

[Guillosanti]

Extra diagnostics:

kubectl -n openshell get secrets

• only sh.helm.release.v1.openshell.v1 exists

kubectl -n openshell describe pod openshell-0

• FailedMount: secret "openshell-server-tls" not found
• FailedMount: secret "openshell-server-client-ca" not found

helm -n openshell get manifest openshell | grep

• secretName: openshell-server-tls
• secretName: openshell-server-client-ca

[Guillosanti]

Also, kubectl -n kube-system logs job/helm-install-openshell reports:

• STATUS: deployed

[theiter8r]

Hi @Guillosanti this seems to be an TLS issue try installing certmanager maunally and then rerun

nemoclaw onboard

the core issue might be if you are on a windows laptop u need to install WLS2 (linux env for this windows)
once you do then redo this stuff from the start and you are good to go

LMK if that helps

[Guillosanti]

Thanks @theiter8r. I am already on WSL2 with Ubuntu 24.04 and Docker Desktop WSL integration working.

I can try installing cert-manager manually. Before I do that, can you confirm whether OpenShell/NemoClaw currently assumes cert-manager is preinstalled on local WSL2 setups?

Right now the cluster reaches the openshell namespace and the Helm release reports deployed, but the TLS secrets openshell-server-tls and openshell-server-client-ca are never created.

[Guillosanti]

Hello @theiter8r, I found the install issue: openshell-0 was stuck in ContainerCreating because the secrets openshell-server-tls and openshell-server-client-ca were missing.
​
The Helm values referenced those secrets with TLS enabled, but the manifest only mounted them and did not create them, and I didn’t see cert-manager resources being rendered.
​
I fixed it by manually generating a self-signed CA/server cert, creating those two secrets in the openshell namespace, and recreating openshell-0. After that, the pod started correctly.

[benhadad]

Will this be addressed by this PR for openshell?
NVIDIA/OpenShell#495

[elezar]

@Guillosanti the PR you mention does not address TLS secret creation on WSL. It only considers injection of device nodes from the host to the gateway container.

[Guillosanti]

Thanks @elezar , that makes sense. My issue on WSL was not GPU/device-node injection but missing TLS secrets in the OpenShell Kubernetes deployment. The pod openshell-0 was stuck because openshell-server-tls and openshell-server-client-ca were not present, and it recovered after I created those secrets manually and recreated the pod. So I agree that the PR is unrelated to the root cause I hit on WSL.

[Guillosanti]

@benhadad I don’t think so. PR #495 appears to address GPU injection in the gateway/bootstrap path by switching to CDI where supported, while my WSL failure was caused by missing Kubernetes TLS secrets (openshell-server-tls and openshell-server-client-ca) preventing openshell-0 from mounting its volumes. So unless the PR also adds secret creation elsewhere, it does not look like a fix for the issue I hit.