port to gofish/redfish v0.19.0 #395
Conversation
There was a problem hiding this comment.
Other than that error wrapping discussion, lgtm. We will have to test this extensively... I'm concerned that we were pulling the start update endpoint from there for a reason other than it not simply being defined elsewhere... some weird vendor nonsense.. Joel likely knows.
This particular method is only called from/used in the SMC X12 provider, so I am less concerned we’ll break unknown providers. That said, I agree that we need to be vigilant here. I am suspicious that redfish is going to be nice with older vintages of BMC software. |
That would make our lives easier, but vendors often implement their own interpretation of redfish. I'm more concerned about the extensive changes that have been introduced since we last updated Gofish - stmcginnis/gofish@v0.15.0...v0.19.0 I suggest holding off the merge until we've tested this with some of our tools (PBnJ, Alloy, Flasher) with this rev on some hardware. One of the main concerns I had was the concurrent processing added here, and how that affects the inventory collection stmcginnis/gofish@a9703ef That hardware test pipeline would have been nice to have here. |
What does this PR implement/change/remove?
As of v0.16.0 StartUpdateTarget is no longer exported from the redfish UpdateService. This breaks the build because we do a raw POST to this endpoint (to retrieve the Task object in the response body). The endpoint for initiating a firmware update via the UpdateService.StartUpdate REST endpoint is actually defined, however (section 6.141.4.4 cf. https://www.dmtf.org/sites/default/files/standards/documents/DSP2046_2024.1.pdf ). This change uses the defined endpoint instead of relying on a property returned by gofish's implementation.
The HW vendor this change applies to (if applicable)
SMC X12