IPMI LAN command story design - try 3rd send

[Vernon Mauery]

On 14-Dec-2017 10:45 PM, Jeremy Kerr wrote:
>Hi Tom,
>
>>> 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...).
>>
>> Yeah all this lack of clarity, arises from a lack of mechanism in IPMI to
>> apply multiple changes (IP address, netmask gateway) together.
>
>No, the specification provides a way to do exactly that:
>
> 1) Change set-complete to 0x01
>
> 2) Send Set LAN Configuration command to update the actual LAN
>    configuration parameters. If more than one parameter is changed, then
>    multiple commands can be sent.
>
> 3) Change set-complete to 0x00
>
>It's just that ipmitool only has code to change one parameter at a time
>at (2). It still does the set-complete process.

I would agree. ipmitool is broken. It should have a 
network-start-configure mechanism that would set the set-complete bit. 
The you could send any number of its network configuration parameters. 
Then it should have a network-finish-configure command that would clear 
the set-complete bit.

In the case where people forget to send the final command, the BMC 
should implement a timeout so it can automatically apply the settings 
and clear the flag after a certain amount of time (10 seconds or more).

It appears that ipmitool had a short period of activity there at the 
beginning of 2017, but not a peep since. I pushed a fix for a bug 
several weeks back and have not heard anything.

--Vernon

>>> 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).
>>
>> I prefer the second option of allowing ipmitool to explicitly clear the
>> set-in-progress flag.
>
>They're not "or" options. We'd need to do both.
>
>> The first option is really  "unusual way" to get this done, to overcome
>> a specification shortcoming.
>
>It's not a specification shortcoming; the specification explicitly
>supports this, it's just that ipmitool doesn't.
>
>The 10-second delay is a server-side workaround for that, and is present
>on other BMC implementations out there. We should implement that
>workaround, because asking everyone to update to a new ipmitool version
>isn't feasible either.
>
>Regards,
>
>
>Jeremy