phosphor-ipmi-flash: Next Iteration of Control

[Adriana Kobylak]

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).

> 
> 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.

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