phosphor-ipmi-flash: Next Iteration of Control

[Milton Miller II]

On  06/28/2019 at 05:21PM in some timezone,  Patrick Venture wrote:
>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.

Unfornately a simple target may be difficult:  Currently 
prepare-for-flash-update may curretnly set a firmware variable that 
requires a BMC reboot to take effect.  In this mode, the initramfs 
copies the file system to RAM during startup so theat the flash is 
available for writing the replacement image.  (Doing this step 
allows the flash to be written while full services are written).

I suppose this could be turned into a target, but it would imply 
a BMC reboot loosing other sessions and may be unexpected.  The 
existing targets would need to be modified to recognise the 
system is in this state and NOP (currently it can not be 
deterimined if you are currently in the state otther than 
unreliably peeking at /proc/mounts).

Not to say having the targets is a bad idea, just that it might 
require a bit more work.

milton

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