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

オープン
  • 何か問題がありますか？
#383 コメント 18 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
powershell, python
領域
api, infrastructure

調査の方向性

Redfish PowerShell/Invoke-SystemEraseREDFISH.psm1 と Redfish Python/SystemEraseREDFISH.py から始め、BIOS System Erase 後の待機および再接続パスに焦点を当てます。これらを、issue で言及されている既存の "wait for iDRAC" パターンと比較します。完了条件は、両方の実装が上限時間の範囲内でポーリングし、Python が接続レベルの失敗だけでなく、成功しなかった HTTP 応答についても再試行することです。

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
PowerShell
スター
742
フォーク
311
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dell/iDRAC-Redfish-Scripting のほかの issue

dell/iDRAC-Redfish-Scripting の issue をすべて見る

似ている issue

Backend & API Design の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。