IPMI LAN command story design - try 3rd send

[Tom Joseph]

On Wednesday 13 December 2017 08:38 AM, Jeremy Kerr wrote:
> Hi all,
>
> Digging up an old thread here, but I think this is important:
>
>> Thanks for the explanation.  With this website you pointed to and some
>> other investigation I've done, I am comfortable with us using the 'Set
>> Channel Access' as the time to apply the settings.  The documentation of
>> two competition products both seem to require an 'ipmitool mc reset
>> warm' for IP address changes to take effect, so we are at least better
>> than that.
> The two BMC implementations that I'm aware of do not require a mc reset
> for lan parameters to be applied. Both will apply settings without
> further commands. One will wait 10 seconds before applying settings, to
> allow multiple changes to be grouped into a single reconfiguration.
>
> 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 is not clear to me from the IPMI specification, on which 
command/condition
  the BMC network settings are applied. The BMC implementation that 
applies the
  settings after `10` sec does it after which parameter? It sounds like 
an OEM/custom
way of doing and not based on IPMI specification.

If you can provide more details on how it is done on the BMC 
implementation, we
can consider it as a way to implement this command.

>
>> Can you internally track down a contact on the xCAT team and verify that
>> this will be ok with them?
> Not just xCAT, but every other provisioning software that will support
> OpenBMC. Including ones that are custom-developed. That's not feasible.
>
> For cases like this, we should really reconsider before coming up with
> our own special interface requirements.
>
> Regards,
>
>
> Jeremy
>