IPMI LAN command story design - try 3rd send
austenc at us.ibm.com
Thu Dec 14 03:55:49 AEDT 2017
"openbmc" <openbmc-bounces+austenc=us.ibm.com at lists.ozlabs.org> wrote on
12/12/2017 09:08:01 PM:
> From: Jeremy Kerr <jk at ozlabs.org>
> To: Patrick Williams <patrick at stwcx.xyz>, tomjose
<tomjose at linux.vnet.ibm.com>
> Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
> Date: 12/12/2017 09:08 PM
> Subject: Re: IPMI LAN command story design - try 3rd send
> Sent by: "openbmc" <openbmc-bounces+austenc=us.ibm.com at lists.ozlabs.org>
> 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
> > 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
> > Can you internally track down a contact on the xCAT team and verify
> > 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.
Would this make sense for this to become a topic for the OpenBMC
leadership? I have to imagine all companies hit this issue.
Maybe even reach out to Mr Cory Minyard ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openbmc