preventing chassis power-on until bmc Ready

[Andrew Geissler]

Greetings,

We at IBM have been finding cases where we wrote our services in a way that they
assume the BMC has reached "Ready" state prior to a chassis power on and host
firmware boot being allowed to start. For example, to power on the chassis, you
need to have collected all of the vpd associated with the VRM's and power
supplies. This vpd collection occurs on the way to BMC Ready, and services
in the power on target assume it's all been collected. We have other scenarios
like this and we're wondering if we continue to whack-a-mole by fixing
these individually with explicit service dependencies or do something a bit
more global to ensure our systems aren't allowed to power on until the BMC
has reached the "Ready" state. This state ensures all inventory and other
system data has been collected and created on d-bus.

The BMC reaches the "Ready" state once all services within the multi-user.target
have successfully started running.

I know in the past I've heard of servers that allow both the BMC and Host
to boot in parallel (which sounds awesome) but we're not there yet. I'm
contemplating an optional package in phosphor-state-manager that could be
installed and put in the obmc-chassis-poweron at .target and prevent
any other services running until the BMC reached Ready.

The obmc-chassis-poweron at .target does have a "After=multi-user.target" within
it but that doesn't control the services within the poweron target. It just
ensures systemd will not consider the obmc-chassis-poweron at .target complete
until multi-user.target has completed.

Anyone else have a similar issue and/or thoughts on this problem?

Thanks,
Andrew