phosphor-ipmi-flash: Next Iteration of Control

[Patrick Venture]

On Fri, Jun 28, 2019 at 12:56 PM Adriana Kobylak <anoo at linux.ibm.com> wrote:
>
> On 2019-06-28 13:37, Patrick Venture wrote:
> > I was thinking, since I'm going to extend phosphor-ipmi-flash to
> > support updating a BIOS -- it might make sense to make it more general
> > further.  I was thinking about how right now, there are default
> > services you can implement for each thing, prepare, verify, update,
> > and currently we don't install them (although I was going to implement
> > a default prepare service).
> >
> > I was thinking that possibly adoption would be easier if they were
> > targets instead of service files directly and then we'd always install
> > the targets:
> >
> > - phosphor-ipmi-flash-prepare-update.target (always called when
> > starting up a process each time a new process is started)
> > - phosphor-ipmi-flash-verify-bmc.target
> > - phosphor-ipmi-flash-update-bmc.target
> >
> > Then a user can just install their services into the targets and not
> > have to really worry about doing anything more.  I think it's equally
> > as usable as before, but ... I don't know.  This way, it always
> > installs the targets.
>
> Yeah I think it'd make it more obvious to have the targets installed
> than
> having optional services. Also this could allow services to be started
> in parallel, like verifying 2 different images at the same time
> triggered
> by the target (just thinking out loud).

Yeah, someone mentioned needing to run additional services, and
although they could chain them from the initial service, might be
easier with just having a target.  So, I'm going to roll that patch
into review today.  It'll require some recipe changes, but otherwise I
don't anticipate any issues.

>
> >
> > I was thinking about this further and was thinking about how
> > everything is compiled into the application, dynamically/configurable,
> > but compiled in.
> >
> > If it's going to start supporting BIOS, and then later other firmware,
> > perhaps the list of Blobs and their associated actions should be
> > configured via json.  There is a limitation to this though that if
> > that's the case, then the ActionInterface used for different things
> > would really just become a SystemdActionInterface and we'd use
> > services to control everything.  In theory, the json could specify the
> > ActionInterfaceType from a list and the parameters after that point
> > would be per type..., but I think that's getting a bit easy-to-break.
>
> Yeah, maybe we wait to see if anybody would prefer not having to compile
> the
> tool with the available options.

Yeah.  I'll play around with it a bit and submit patches next week.
Still need to do more testing, and it's missing some tests :)

>
> >
> > Those are just some thoughts I had today.
> >
> > Regards,
> > Patrick