Redfish Software Updates in OpenBMC

[Andrew Geissler]

On Tue, Jan 22, 2019 at 9:26 AM Andrew Geissler <geissonator at gmail.com> wrote:
>
> 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.

I put a design doc up at
https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/18186/
I hemmed and hawed a bit on whether it was needed but figured with all
our recent community discussions, it's better to over communicate then
under.

Andrew