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



More information about the openbmc mailing list