Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

System Erase's post-reset "wait for iDRAC, then power on" step: PowerShell's fixed wait has ~0 margin in practice; Python's retry loop looks unguarded against connection-level failures

Aperta
  • Qualcosa non va?
#383 18 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
58/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
powershell, python
Ambito
api, infrastructure

Direzione di ricerca

Inizia da Redfish PowerShell/Invoke-SystemEraseREDFISH.psm1 e Redfish Python/SystemEraseREDFISH.py, concentrandoti sui percorsi di attesa e riconnessione successivi a BIOS System Erase. Confrontali con il pattern esistente "wait for iDRAC" menzionato nell’issue. Il lavoro è completato quando entrambe le implementazioni eseguono il polling entro un limite massimo vincolato e Python ritenta sia in caso di errori a livello di connessione sia in caso di risposte HTTP non riuscite.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Scope: PowerShell (Set-DeviceFirmwareSimpleUpdateREDFISH's System Erase path is not involved here — this is specifically Invoke-SystemEraseREDFISH.psm1 and its Python counterpart SystemEraseREDFISH.py, both under Redfish PowerShell/ / Redfish Python/). Related to, but distinct from, the break-escaping-caller's-loop issue reported separately.

Summary

After a System Erase job that includes the BIOS component completes, both implementations wait a fixed amount of time for iDRAC to come back up before attempting to power the server back on:

  • PowerShell (Invoke-SystemEraseREDFISH.psm1): waits a fixed 5 minutes, then attempts to reconnect essentially once (two closely-spaced POST attempts with no delay or retry loop between them), giving up immediately on failure.
  • Python (SystemEraseREDFISH.py): waits a fixed 6 minutes, then retries up to 5 times with a 60-second delay between attempts if the connection succeeds but returns a non-success HTTP status — but the requests.post(...) calls in that retry loop aren't wrapped in a try/except, so a connection-level failure (iDRAC not yet listening at all, rather than iDRAC responding with an error) looks like it would raise an unhandled exception and crash the script outright, rather than being retried the way an HTTP-level error is.

Real timing data

Ran a System Erase (CryptographicErasePD,IDRAC,BIOS) against a PowerEdge R6615 and captured full timestamped logs. Two independent runs both hit the PowerShell 5-minute wait's failure case; here's the exact breakdown from the more recent one:

18:13:51.447  Stage 1 starts - about to call Invoke-SystemEraseREDFISH
18:22:59.430  Cmdlet's buffered output appears (call has returned) -
              includes "System Erase job execution time: Minutes: 4, Seconds: 0"
              and two "Unable to connect to the remote server" failures
              after the documented "wait 5 minutes for iDRAC" step
  • Total call duration: 547.98s
  • Erase job's own reported polling time: 240s (4:00)
  • Remainder (setup + the 5-minute wait + 2 failed reconnects + overhead): 307.98s — only 7.98 seconds of that is not the nominal 300s wait, meaning both reconnect attempts fired right at the 5:00 mark with essentially no margin.
  • Our own follow-up connectivity check, run immediately after the cmdlet returned (2.35s later, after closing an unrelated browser window), succeeded on its first attempt in 42ms.

So iDRAC was reachable only a few seconds after the module gave up — the wait wasn't drastically too short, it just had zero margin, and across 2/2 real attempts that margin wasn't enough.

Suggested fix

Rather than picking a new fixed number (hardware/network variability means any constant will eventually be violated again), replace the fixed-wait-then-give-up pattern with a bounded polling loop: check every 15–30s for up to some generous ceiling (10–15 minutes), succeeding as soon as iDRAC responds instead of gambling on one guessed duration. This is the same pattern already used successfully elsewhere for "wait for iDRAC" scenarios.

For the Python side specifically, independent of the wait duration: wrapping the requests.post(...) calls in that retry loop in a try/except for connection errors (treating them the same as a non-success status code — log and retry after the existing 60s delay) would close what looks like a real gap, since the scenario the retry loop exists to handle (iDRAC not up yet) is exactly the case most likely to raise a connection error rather than return an HTTP status at all.

Environment

  • Windows PowerShell 5.1, Dell PowerEdge R6615, iDRAC9
  • Checked against the current master branch of both the PowerShell and Python implementations
Lingua principale
PowerShell
Stelle
739
Fork
310
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dell/iDRAC-Redfish-Scripting

Tutte le issue di dell/iDRAC-Redfish-Scripting

Issue simili

Altre issue su Backend & API Design

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.