IPMI LAN command story design - try 3rd send

[Jeremy Kerr]

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.

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