Handle different response in storage data for redfish api

[chanchiwai-ray]

• Did minor clean up of unused code
• Reorder logic in _verify_redfish_call
• Cherry-pick commits from handle different storage controller responses #58 since it's no longer active

[jneo8]

Non-blocking question.

[chanchiwai-ray]

Encounter this also microsoft/linux-package-repositories#130

[dashmage]

Thanks for the PR! This probably resolves #177, but I'm not sure about #222, #69. For those, we might have to check with the bug reporters themselves and see if the redfish API uses Controllers there as well or if it's something else altogether to fetch the storage controller info.

#115 seems like the standard case but not sure why there's still an error.

[chanchiwai-ray]

but I'm not sure about canonical/hardware-observer-operator#222, #69. For those, we might have to check with the bug reporters themselves and see if the redfish API uses Controllers there as well or if it's something else altogether to fetch the storage controller info.

Agree. That can be an enhancement proposal from them if they require it, or they find out more possible "keys". But at least they will not see the KeyError after this.

canonical/hardware-observer-operator#115 seems like the standard case but not sure why there's still an error.

Same here, they will not see KeyError after this, but with more debugging information, so that user can propose enhancement, instead of reporting KeyError which is not informative

[dashmage]

LGTM 🚀 Thanks for addressing my comments! Also, adding the extra else block and fetching data from the dict properly to ensure there's no KeyError related errors is a great idea.