昨年オープンしたSLサポートチケットでは、私のチームがBaremetalサーバーにカスタムスクリプトを注文したときに、プロビジョニングプロセス中に新しいBMサーバーに関連付けられたサーバーIDが変更されることがあります。その時点で、私のツールはそのツールを失い、失敗します。このチケットには:REST APIを使用して新しくプロビジョニングしたBareMetalサーバーのステータスを確実に追跡する方法
私はサーバIDの代わりにグローバル識別子を使用する必要があることを言われました。ついにそれを試してみましたが、私は問題を見ています。私がサーバーIDでできるように、最初に要求を提出したときに、グローバルIDを使用して新しいサーバーのハードウェアステータスを照会することはできないようです。
[[email protected] tools]$ curl -k -u chrisr1:<PW> "https://api.softlayer.com/rest/v3/SoftLayer_Hardware/320526/getHardwareStatus.json"
{"id":3,"status":"DEPLOY"}
[[email protected] tools]$ curl -k -u chrisr1:<PW> "https://api.softlayer.com/rest/v3/SoftLayer_Hardware/75302613-e55a-481a-829f-967799a41968/getHardwareStatus.json"
null
ただし、後で動作します。私は準備が整ったすべてのサーバーに対して同じクエリを実行しました。
私はその上で照会することができる識別子である必要[[email protected] tools]$ curl -sS -k -u chrisr1:<PW> "https://api.softlayer.com/rest/v3/SoftLayer_Hardware/1ab37f37-9373-4e10-9de4-7319fffcb4f8/getHardwareStatus.json" | json_pp
{
"status" : "ACTIVE",
"id" : 5
}
:
a)に利用できるすぐに、そして
b)は
感謝を変更しません。
これは私がすでにやっていることのようなものです。問題は、サーバーの識別子が変わる可能性があるため、各Hardware/getHardwareStatusコールの前にAccount/getHardwareコールを実行し続ける必要があると思いますか?それは過剰なネットワークトラフィックのようです。 –
しかし、これはプロビジョニングプロセスを終了する前にサーバーの識別子を取得するための1つのオプションです。サーバーがいつプロビジョニングプロセスを完了したかだけを知りたければ、Raulの提案に従ってください。 –
私はこの解決策を使用して巻き上げました。そのIDが突然IDが存在しないことを示す文字列を返す場合、標準の一意のIDを使用してサーバーのステータスを照会している間に、新しいIDを再度ホスト名からマップし直して、その状況の検査を続行します。理想的ではありませんが、機能します。 –