Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

feat(gateway): explain compute driver discovery decisions

Offen
  • Stimmt etwas nicht?
#3,211 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
docker, rust
Bereich
backend, observability

Rechercherichtung

Beginne beim in der Untersuchung beschriebenen gemeinsamen Pfad zur Ermittlung des lokalen API-Sockets, an dem Fehler bei HTTP-Sonden über Unix-Sockets zu einem Ergebnis „nicht verfügbar“ zusammengefasst werden. Verfolge die Pfade für Metadaten, Verbindung, Schreiben, Lesen, Timeout und Antwortvalidierung und verwende anschließend repräsentative erfolgreiche, fehlende und aufgrund fehlender Berechtigungen abgelehnte Ergebnisse, um Diagnosen pro Kandidat, prägnante Startzusammenfassungen und eine sichere Meldung von Endpunkten zu überprüfen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

User Story

As an OpenShell operator, I want the gateway to explain how it selected or rejected local compute drivers, so that I can diagnose startup failures without reproducing them under a debugger.

Problem Statement

Gateway auto-detection probes local driver candidates, such as Docker Unix sockets, but silently treats probe failures as unavailable. When a candidate socket exists but Snap confinement denies access, the gateway eventually reports only that no suitable driver was found and systemd may restart it. Operators cannot tell which candidates were examined, whether a driver was selected, or whether a candidate failed because of a missing socket, an access denial, a timeout, or an unexpected API response.

Impact / Why This Matters

Package and confinement failures are difficult to distinguish from an absent runtime. The current workaround is to manually inspect socket paths, Snap interface connections, and journal output, then infer the cause. That is insufficient for CI and user installations because the decisive probe result is not recorded.

Proposed Design

When gateway driver auto-detection runs, expose diagnostics at debug level that identify each candidate driver and socket probe outcome without logging credentials or other sensitive data. Startup errors should provide a concise summary of the attempted drivers and why no usable driver was selected. A successful selection should state the selected driver and endpoint category in diagnostics.

Acceptance Criteria

  • With debug logging enabled, each local compute-driver candidate records whether it was selected, skipped, or rejected.
  • Docker socket diagnostics distinguish a missing/non-socket path, connection denial, timeout, and an incompatible or unsuccessful API response.
  • Normal startup errors summarize the failed discovery decision without exposing secrets or request contents.
  • A successful auto-detection records the selected driver and does not expose sensitive endpoint data.
  • Coverage verifies representative successful, missing, and permission-denied probe outcomes.

Alternatives Considered

  • Relying only on systemd or Snap logs: these do not report the gateway discovery decision or every candidate it attempted.
  • Treating socket existence as availability: this would hide confinement failures and select unusable drivers.
  • Requiring an explicitly configured driver: useful as a workaround, but does not make default installations diagnosable.

Agent Investigation

Docker discovery currently probes each candidate with a Unix-socket HTTP ping and returns only a boolean result. Failed metadata, connect, write, read, timeout, and response-validation paths are intentionally collapsed into unavailable. This behavior is shared by local API socket discovery and leaves no per-candidate diagnostic trail.

Related: https://github.com/NVIDIA/OpenShell/pull/2869#discussion_r3928619578

Vorherrschende Sprache
Rust
Sterne
15.4k
Forks
1.7k
Ø Merge
1 T. 19 Std.
Gemergte PRs (30 T.)
347

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.