Redfish Software Updates in OpenBMC

[Andrew Geissler]

On Mon, Jan 14, 2019 at 11:04 AM Ed Tanous <ed.tanous at intel.com> wrote:

> On 1/10/19 2:43 PM, Andrew Geissler wrote
> > Redfish defines a UpdateService schema[a]. An action available on the
> > UpdateService is a SimpleUpdate interface. I think the flow to use this would
> > look like this:
> >
> > # Retrieve the URI to upload an image to
> > HttpPushUri = GET  /redfish/v1/UpdateService
> >
> > # Upload firmware image
> > ImageURI = POST HttpPushUri
>
> As redfish is written, this is where the flow stops.  The BMC takes over
> from here, and updates itself.  One enhancement I'd really like to see
> made is to return a reference to a TaskService task, so we can track the
> progress as the update is applied.
>
> My understanding is that SimpleUpdate is a flow where the BMC can pull
> down an image itself, so the URI is generally not something local to the
> BMC, but a remote server that the BMC can connect to.

Looked like the Dell implementation was using it as a local pointer but I agree,
the specification seems to only support the remote server concept. This is
a feature we'll want (like for TFTP and such).

>
> > The main issue with the above is the loss of our ability to have multiple
> > firmware images of the same type in a system and to be able to change the
> > priority of them to switch back and forth between them. It's also not obvious
> > to me what the target is for the BIOS when doing an update of it? There are OEM
> > options for both Actions and Properties if needed (but would be great to avoid).
>
> The piece I think you're missing is the new property that was added in
> redfish UpdateService 1.1.1 named HttpPushUriTargets.  It essentially
> allows you to define multiple targets for the push flow you outlined
> above, although I don't see anyone using it yet.
>
> https://github.com/openbmc/bmcweb/blob/c0eb9bd95afa900dc808dce7c2c5fa521ba828f5/static/redfish/v1/schema/UpdateService_v1.xml#L224
>
> If you want to implement SimpleUpdate, it also supports the Targets
> property, which lets you direct where you would like a given payload to
> be updated to:
>
> https://github.com/openbmc/bmcweb/blob/c0eb9bd95afa900dc808dce7c2c5fa521ba828f5/static/redfish/v1/schema/UpdateService_v1.xml#L74
>
> One design conflict I'm seeing is that Redfish wasn't really meant to
> separate out the upload and activate interfaces.  Personally, I like the
> Redfish approach better, as it simplifies things for the user.  Loading
> a target with firmware is a single step (upload), instead of 2 (upload
> then activate).  Most of the systems I know of use the single step process.

Yeah, I'd like to stick with the default interface and I agree that the one
step process is easier. I would propose though that we add an OEM
"Priority" field so in instances where the system supports multiple
images for the same HttpPushUriTargets, the user would have an easy
way to switch back and forth. We use this a lot in development and
I know customers use it when they want to quickly roll back to a
previous update (when they were just testing out a new release or
run into issues with it). Some investigation will be required by me to
determine if the existing API's would support multiple firmware instances
for the same Target.