IPMI LAN command story design - try 3rd send
Jeremy Kerr
jk at ozlabs.org
Thu Dec 14 23:30:03 AEDT 2017
Hi Tom,
>> Requiring non-standard command to be issued causes a disconnect between
>> user expectations and our implementation. We'd have to document this
>> difference in behaviour for every potential sysadmin interacting with
>> OpenBMC.
> The command to apply BMC network settings on OpenBMC IPMI reference
> implementation is set channel access, which is a standard command
> mentioned in the IPMI specification.
It may be a standard command, but using it in this context certainly
isn't standard, nor even a common convention.
The issue is that we're introducing an "unusual" step for this
configuration process, and expecting all users to know about it.
> It is not clear to me from the IPMI specification, on which
> command/condition
> the BMC network settings are applied.
Ideally, the settings should be applied as soon as the 'Set in progress'
flag indicates that the change is complete.
Adding the 10-second delay allows users to "batch" multiple changes,
meaning that network connectivity isn't lost between those changes. This
is purely to allow ipmitool (which doesn't have a facility to make
multiple changes before indicating that the change is complete) to be
used over the network to change the lan configuration (which is a bit
risky regardless...).
For doing this over the in-band interface, there is no harm in applying
the settings immediately.
To implement something complying to a "principle of least surprise", I'd
suggest that we should:
- batch changes, and have them applied after 10 seconds from clearing
the set-in-progress flag
- submit patches to ipmitool to allow multiple changes to be applied
at once (ie, one clearing of the set-in-progress flag).
Regards,
Jeremy
More information about the openbmc
mailing list