[ericcurtin]

Summary

Show why a Kubernetes sandbox pod is unscheduled.

Related Issue

Closes #4746

Changes

• Map FailedScheduling events to a generic create progress detail.
• Report PodScheduled=False (Unschedulable) in sandbox status while not Ready, with a generic message.
• Keep the raw scheduler message in gateway logs only.
• Add a short docs note.

Testing

• Checks appropriate to the affected code and behavior pass
• Unit tests added/updated (if applicable)
• E2E tests added/updated (if applicable)

cargo test, cargo clippy -D warnings and cargo fmt --check on openshell-driver-kubernetes.

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[ericcurtin]

@TaylorMutch PTAL, and /ok to test 07bfc866afd040861f97884d7734424d9b667931 if it looks good. Thank you!

[ericcurtin]

@drew @sjenning PTAL when you get a chance, and /ok to test 07bfc866afd040861f97884d7734424d9b667931 if it looks good. Thank you!

[ericcurtin]

@krishicks @matthewgrossman PTAL when you get a chance, and /ok to test 07bfc866afd040861f97884d7734424d9b667931 if it looks good. Thank you!

[ericcurtin]

@drew @mrunalp PTAL when you get a chance, and /ok to test 07bfc866afd040861f97884d7734424d9b667931 if it looks good. Thank you!

[TaylorMutch]

/ok to test 07bfc86

[TaylorMutch]

Could we restrict the raw Kubernetes scheduler message to OpenShell admins and expose a generic scheduling status to end users?

In a shared deployment, sandbox users may not be authorized to inspect the underlying cluster. Scheduler diagnostics can reveal node counts, resource constraints, taints, and placement details. This change copies the raw message into sandbox status, making that infrastructure information available through the user-facing API. The FailedScheduling progress detail also forwards the raw message, so both paths need the same visibility boundary.

Some raw diagnostics already reach users through platform events, but making them persistently available in sandbox status expands that exposure. A generic message such as “Waiting for cluster capacity or a compatible node” would preserve useful progress feedback for end users, while OpenShell admins could retain access to the full diagnostic. Can we establish that separation before landing this?

[ericcurtin]

@TaylorMutch done: sandbox status and progress detail now show a generic "Waiting for cluster capacity or a compatible node"; the raw scheduler message stays in gateway logs. Could you /ok to test cb4ab29? Thank you!

[TaylorMutch]

/ok to test cb4ab29