<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Emily, you at Google must have heavily refactored ipmitool to use
it as a library because 'as is' it is completely thread-unsafe,
non-reentrant, and overall... ehm... low quality. From my
experience, OpenIPMI is much more useful as a library.</p>
<p>Thanks for pointing to the openbmc ipmitool repo.<br>
</p>
<p>Alexander.<br>
</p>
23.03.2018 00:57, Emily Shaffer wrote:<br>
<blockquote type="cite"
cite="mid:CAJoAoZmUgRv5LeDYXhNhdNtJqfew7aAqBP-v=Ss6mQRQcuDFHA@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">FWIW - OpenBMC does seem to have a fork of
ipmitool... I don't think we've done much to it. <a
href="https://github.com/openbmc/ipmitool"
moz-do-not-send="true">https://github.com/openbmc/ipmitool</a>
<div><br>
</div>
<div>However, that doesn't fix the problem you mention, that
it's likely not the same version packaged with the host's
image, and that that version is in burned-out-maintainer
limbo. That's why I'd prefer to do what we can to view
ipmitool as immutable, to make it easier for someone to use
OpenBMC with their system.</div>
<div><br>
</div>
<div>To flip one last time, though, at Google we use ipmitool as
a library and wrap it in another internal utility, and so we
can make changes either to ipmitool itself or two how we call
it really easily. I wonder whether many other OpenBMC users
who care about IPMI are doing something similar to us.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr">On Wed, Mar 21, 2018 at 7:55 AM Alexander Amelkin
<<a href="mailto:a.amelkin@yadro.com"
moz-do-not-send="true">a.amelkin@yadro.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Just my 2
cents.<br>
<br>
I did previously some commits to the ipmitool project, and can
tell that<br>
fixing ipmitool upstream now doesn't seem feasible as the only
active<br>
project maintainer (Zdenek Styblik) has called it quits about
a year<br>
ago. I've tried asking him to make me an admin of the project
he doesn't<br>
want to maintain anymore, but he just stopped responding.<br>
<br>
I'm thinking about forking off (actually did it to YADRO
organization on<br>
github) and starting to maintain our own version of ipmitool.
That<br>
however doesn't solve the problem as the original ipmitool is
a part of<br>
all the available Linux distros, and making their maintainers
switch to<br>
our version I anticipate to be hell of a quest...<br>
<br>
Applying the changes with a timeout after the set-complete
looks good to<br>
me as it both follows the specification and allows for
addressing the<br>
incorrect behavior of the original ipmitool.<br>
<br>
Alexander.<br>
<br>
<br>
13.03.2018 18:36, Tom Joseph wrote:<br>
> Hello,<br>
><br>
> There is a patch up for applying the network settings,
with this patch<br>
> it would not require set channel access command to apply
the changes.<br>
> A timer kicks in everytime set-complete happens, and the
network<br>
> settings are applied once the timer expires.<br>
><br>
> <a
href="https://gerrit.openbmc-project.xyz/#/q/topic:2932"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://gerrit.openbmc-project.xyz/#/q/topic:2932</a><br>
><br>
> Regards,<br>
> Tom<br>
><br>
> On Thursday 15 February 2018 02:23 AM, Vernon Mauery
wrote:<br>
>> On 14-Feb-2018 12:32 PM, Patrick Venture wrote:<br>
>>> I thought you had to explicitly set in_progress
with the ipmitool? My<br>
>>> own ipmitool utility is implemented as you
described where it doesn't<br>
>>> assume anything about your intent, just follows
the actions.<br>
>><br>
>> Currently, ipmitool (incorrectly) sets the "set in
progress" bit for<br>
>> every lan configuration parameter it sets. Given how
the CLI<br>
>> interface only allows the user to specify a single
parameter at a<br>
>> time, it might be smart to have ipmitool also expose
controls for the<br>
>> "set in progress" bit. Alternately, providing a way
to to specify<br>
>> multiple parameters in a single call would be good.
Something like:<br>
>><br>
>> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0
gateway 1.2.0.1<br>
>> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp<br>
>><br>
>> and it would automatically set and use the set in
progress bit<br>
>> correctly.<br>
>><br>
>> And ipmid could then take two actions, depending on
how this bit is<br>
>> (ab)used:<br>
>> 1) if only a single command is wrapped up in the<br>
>> set-in-progress/set-complete, then employ a timeout
so that after<br>
>> some amount of time, all the queued commands get
applied.<br>
>> 2) if multiple commands get wrapped up in the<br>
>> set-in-progress/set-complete, then apply the command
set when the<br>
>> set-complete is received.<br>
>><br>
>> Getting ipmitool changed to have correct behavior
will take some<br>
>> doing, so we will need to be able to deal with its
incorrect behavior<br>
>> for now. But also responding to correct behavior can
make tools that<br>
>> employ that behavior work even better (with no
timeout delays).<br>
>><br>
>> Just my $0.02.<br>
>><br>
>> --Vernon<br>
>><br>
>>> There's definitely the possibility of thrashing.<br>
>>><br>
>>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley<br>
>>> <<a
href="mailto:david.j.cobbley@linux.intel.com"
target="_blank" moz-do-not-send="true">david.j.cobbley@linux.intel.com</a>>
wrote:<br>
>>>> Do you have any concerns about ipmitool
constantly flushing the<br>
>>>> network as<br>
>>>> it sets & unsets the complete bit
inbetween parameters,<br>
>>>> i.e. if you are setting 4 different
parameters from a script?<br>
>>>><br>
>>>> I'm not sure if this brings a lot of
thrashing to the to the ipmi<br>
>>>> network<br>
>>>> stack or network manager.<br>
>>>><br>
>>>> Seems like it would be prudent to fix
ipmitool upstream to allow<br>
>>>> you to set<br>
>>>> multiple parameters, in addition to the ipmi
stack.<br>
>>>><br>
>>>><br>
>>>>> I personally have found this non-standard
implementation a bit<br>
>>>>> unpleasant, as it requires using a
different command to basically<br>
>>>>> flush it. I am planning to implement it
such that setting in<br>
>>>>> progress<br>
>>>>> before and complete after is how it all
gets flushed instead of a<br>
>>>>> timeout, since that approach reads more
correct given the<br>
>>>>> specification. And really it's just
about literally calling a<br>
>>>>> subroutine to flush everything when the
in_progress bit is set to<br>
>>>>> completed, and removing the code from
"access on"<br>
>>>>><br>
>>>>> If you're interested to do what I've just
described, I don't think<br>
>>>>> you'll get any push-back.<br>
>>>>><br>
>>>>> Patrick<br>
>>>>><br>
>>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave
Cobbley<br>
>>>>> <<a
href="mailto:david.j.cobbley@linux.intel.com"
target="_blank" moz-do-not-send="true">david.j.cobbley@linux.intel.com</a>>
wrote:<br>
>>>>>><br>
>>>>>> I noticed that when using ipmitool
lan set <channel> <parameter>,<br>
>>>>>> the<br>
>>>>>> openbmc stack does not apply the
settings. This seems like a<br>
>>>>>> non-standard<br>
>>>>>> implementation. While using ipmitool
as the standard is not quite<br>
>>>>>> correct,<br>
>>>>>> customers do expect it to work.<br>
>>>>>><br>
>>>>>> After sending any sort of lan set
command with ipmitool, the changes<br>
>>>>>> don't<br>
>>>>>> appear to stick and this message
shows up in the journal:<br>
>>>>>> "Use Set Channel Access command
to apply"<br>
>>>>>><br>
>>>>>> I know IPMI 2.0 is a little ambiguous
about implementation<br>
>>>>>> specifics, but<br>
>>>>>> I<br>
>>>>>> believe the intention was to utilize
the "Set In Progress" bit<br>
>>>>>> (Parameter<br>
>>>>>> 0)<br>
>>>>>> while doing work, and use "Set
Complete" when you are finished to<br>
>>>>>> flush<br>
>>>>>> the<br>
>>>>>> changes.<br>
>>>>>><br>
>>>>>> To work around ipmitool constantly
setting and unsetting the "Set In<br>
>>>>>> Progress" bit in between every
parameter applied, some BMC stacks<br>
>>>>>> accumulate<br>
>>>>>> network changes over a period of time
and apply after a timeout -<br>
>>>>>> this is<br>
>>>>>> also compatible with ipmitool's
non-standard use of the "Set In<br>
>>>>>> Progress"<br>
>>>>>> bit.<br>
>>>>>><br>
>>>>>><br>
>>>>>> Is there a plan to circle back and
change this functionality to<br>
>>>>>> work with<br>
>>>>>> ipmitool in the future?<br>
>>>>>><br>
>>>>>> Thanks,<br>
>>>>>> -Dave Cobbley<br>
>>>>>><br>
>>>><br>
>><br>
><br>
<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>