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

feat: standardize timeout environment-variable semantics

Offen
  • Stimmt etwas nicht?
#3,078 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
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
helm, kubernetes, rust
Bereich
cli, devops, documentation, testing

Rechercherichtung

Beginne damit, das Parsing und die Validierung der benannten Timeout-Umgebungsvariablen nachzuverfolgen, einschließlich des durch PR #3001 eingeführten Lebenszyklusmusters, und untersuche die bestehende CLI, die Bereitstellungsdokumentation und die automatisierten Tests. Erledigt bedeutet, dass die Konvention Einheiten, Standardwerte, Null, ungültige und außerhalb des zulässigen Bereichs liegende Werte abdeckt; betroffene Variablen ihr folgen oder Ausnahmen dokumentieren; und Tests sowie benutzerseitige Dokumentation das gewählte Verhalten widerspiegeln.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

state:stale

User Story

As an OpenShell operator or automation author, I want timeout environment variables to have consistent, documented zero and invalid-value behavior, so that configuration does not unexpectedly cause commands to fail immediately or wait forever.

Problem Statement

OpenShell exposes timeout environment variables with inconsistent parsing and zero-value semantics. For example, OPENSHELL_PROVISION_TIMEOUT and proposed OPENSHELL_LIFECYCLE_TIMEOUT parse 0 as an immediate deadline, OPENSHELL_BUILD_NO_PROGRESS_TIMEOUT_SECS falls back to its default for zero or invalid values, OPENSHELL_VAULT_TIMEOUT_SECS rejects zero, and the local Helm collector timeout passes 0s to kubectl rollout status, where it means wait indefinitely.

This makes it difficult to safely configure automation and obscures whether zero means disabled, immediate, default, or unlimited.

Impact / Why This Matters

Operators must infer each variable's contract from implementation details. A copied value such as 0 can cause a CLI workflow to fail immediately or a local cluster setup to block indefinitely. Invalid values also vary between being silently ignored and causing a clear error, making configuration mistakes harder to detect.

Proposed Design

Define and document a shared timeout environment-variable contract for OpenShell-owned tooling. For each timeout setting, specify its unit, default, valid range, behavior for zero, and behavior for invalid or out-of-range values. Apply the chosen contract consistently where practical, while retaining an explicitly documented exception only when the underlying dependency imposes a different meaning.

Acceptance Criteria

  • The project has a documented timeout environment-variable convention covering units, defaults, zero, invalid, and out-of-range values.
  • The contract is applied or an explicit exception is documented for OPENSHELL_PROVISION_TIMEOUT, OPENSHELL_LIFECYCLE_TIMEOUT, OPENSHELL_BUILD_NO_PROGRESS_TIMEOUT_SECS, OPENSHELL_VAULT_TIMEOUT_SECS, OPENSHELL_STOP_TIMEOUT, and HELM_K3S_COLLECTOR_HEALTH_TIMEOUT.
  • CLI-facing timeout environment variables reject invalid configuration with actionable errors, or deliberately and consistently fall back with that behavior documented.
  • Automated tests cover the selected zero and invalid-value behavior for affected OpenShell-owned timeout parsing.
  • User-facing CLI and deployment documentation states the selected semantics.

Alternatives Considered

Leave each timeout setting to its owning component. This preserves existing behavior but keeps configuration surprising across adjacent workflows and makes automation less portable.

Agent Investigation

  • OPENSHELL_PROVISION_TIMEOUT=0 produces an immediate provisioning-idle timeout.
  • PR #3001 introduces OPENSHELL_LIFECYCLE_TIMEOUT with the same parsing pattern and therefore the same zero behavior.
  • OPENSHELL_BUILD_NO_PROGRESS_TIMEOUT_SECS accepts only positive parsed values; zero and invalid values use the 1800-second default.
  • Vault validation rejects non-positive timeout_secs.
  • kubectl rollout status --timeout=0s waits indefinitely, so the Helm local-development setting has distinct zero semantics.
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.