* IPMI Set LAN Configuration Parameters @ 2018-02-14 17:14 Dave Cobbley 2018-02-14 18:32 ` Patrick Venture 0 siblings, 1 reply; 9+ messages in thread From: Dave Cobbley @ 2018-02-14 17:14 UTC (permalink / raw) To: OpenBMC Maillist I noticed that when using ipmitool lan set <channel> <parameter>, the openbmc stack does not apply the settings. This seems like a non-standard implementation. While using ipmitool as the standard is not quite correct, customers do expect it to work. After sending any sort of lan set command with ipmitool, the changes don't appear to stick and this message shows up in the journal: "Use Set Channel Access command to apply" I know IPMI 2.0 is a little ambiguous about implementation specifics, but I believe the intention was to utilize the "Set In Progress" bit (Parameter 0) while doing work, and use "Set Complete" when you are finished to flush the changes. To work around ipmitool constantly setting and unsetting the "Set In Progress" bit in between every parameter applied, some BMC stacks accumulate network changes over a period of time and apply after a timeout - this is also compatible with ipmitool's non-standard use of the "Set In Progress" bit. Is there a plan to circle back and change this functionality to work with ipmitool in the future? Thanks, -Dave Cobbley ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-02-14 17:14 IPMI Set LAN Configuration Parameters Dave Cobbley @ 2018-02-14 18:32 ` Patrick Venture 2018-02-14 19:16 ` Dave Cobbley 0 siblings, 1 reply; 9+ messages in thread From: Patrick Venture @ 2018-02-14 18:32 UTC (permalink / raw) To: Dave Cobbley; +Cc: OpenBMC Maillist I personally have found this non-standard implementation a bit unpleasant, as it requires using a different command to basically flush it. I am planning to implement it such that setting in progress before and complete after is how it all gets flushed instead of a timeout, since that approach reads more correct given the specification. And really it's just about literally calling a subroutine to flush everything when the in_progress bit is set to completed, and removing the code from "access on" If you're interested to do what I've just described, I don't think you'll get any push-back. Patrick On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley <david.j.cobbley@linux.intel.com> wrote: > I noticed that when using ipmitool lan set <channel> <parameter>, the > openbmc stack does not apply the settings. This seems like a non-standard > implementation. While using ipmitool as the standard is not quite correct, > customers do expect it to work. > > After sending any sort of lan set command with ipmitool, the changes don't > appear to stick and this message shows up in the journal: > "Use Set Channel Access command to apply" > > I know IPMI 2.0 is a little ambiguous about implementation specifics, but I > believe the intention was to utilize the "Set In Progress" bit (Parameter 0) > while doing work, and use "Set Complete" when you are finished to flush the > changes. > > To work around ipmitool constantly setting and unsetting the "Set In > Progress" bit in between every parameter applied, some BMC stacks accumulate > network changes over a period of time and apply after a timeout - this is > also compatible with ipmitool's non-standard use of the "Set In Progress" > bit. > > > Is there a plan to circle back and change this functionality to work with > ipmitool in the future? > > Thanks, > -Dave Cobbley > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-02-14 18:32 ` Patrick Venture @ 2018-02-14 19:16 ` Dave Cobbley 2018-02-14 20:32 ` Patrick Venture 0 siblings, 1 reply; 9+ messages in thread From: Dave Cobbley @ 2018-02-14 19:16 UTC (permalink / raw) To: openbmc, Patrick Venture Do you have any concerns about ipmitool constantly flushing the network as it sets & unsets the complete bit inbetween parameters, i.e. if you are setting 4 different parameters from a script? I'm not sure if this brings a lot of thrashing to the to the ipmi network stack or network manager. Seems like it would be prudent to fix ipmitool upstream to allow you to set multiple parameters, in addition to the ipmi stack. > I personally have found this non-standard implementation a bit > unpleasant, as it requires using a different command to basically > flush it. I am planning to implement it such that setting in progress > before and complete after is how it all gets flushed instead of a > timeout, since that approach reads more correct given the > specification. And really it's just about literally calling a > subroutine to flush everything when the in_progress bit is set to > completed, and removing the code from "access on" > > If you're interested to do what I've just described, I don't think > you'll get any push-back. > > Patrick > > On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley > <david.j.cobbley@linux.intel.com> wrote: >> I noticed that when using ipmitool lan set <channel> <parameter>, the >> openbmc stack does not apply the settings. This seems like a non-standard >> implementation. While using ipmitool as the standard is not quite correct, >> customers do expect it to work. >> >> After sending any sort of lan set command with ipmitool, the changes don't >> appear to stick and this message shows up in the journal: >> "Use Set Channel Access command to apply" >> >> I know IPMI 2.0 is a little ambiguous about implementation specifics, but I >> believe the intention was to utilize the "Set In Progress" bit (Parameter 0) >> while doing work, and use "Set Complete" when you are finished to flush the >> changes. >> >> To work around ipmitool constantly setting and unsetting the "Set In >> Progress" bit in between every parameter applied, some BMC stacks accumulate >> network changes over a period of time and apply after a timeout - this is >> also compatible with ipmitool's non-standard use of the "Set In Progress" >> bit. >> >> >> Is there a plan to circle back and change this functionality to work with >> ipmitool in the future? >> >> Thanks, >> -Dave Cobbley >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-02-14 19:16 ` Dave Cobbley @ 2018-02-14 20:32 ` Patrick Venture 2018-02-14 20:53 ` Vernon Mauery 0 siblings, 1 reply; 9+ messages in thread From: Patrick Venture @ 2018-02-14 20:32 UTC (permalink / raw) To: Dave Cobbley; +Cc: OpenBMC Maillist I thought you had to explicitly set in_progress with the ipmitool? My own ipmitool utility is implemented as you described where it doesn't assume anything about your intent, just follows the actions. There's definitely the possibility of thrashing. On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley <david.j.cobbley@linux.intel.com> wrote: > Do you have any concerns about ipmitool constantly flushing the network as > it sets & unsets the complete bit inbetween parameters, > i.e. if you are setting 4 different parameters from a script? > > I'm not sure if this brings a lot of thrashing to the to the ipmi network > stack or network manager. > > Seems like it would be prudent to fix ipmitool upstream to allow you to set > multiple parameters, in addition to the ipmi stack. > > >> I personally have found this non-standard implementation a bit >> unpleasant, as it requires using a different command to basically >> flush it. I am planning to implement it such that setting in progress >> before and complete after is how it all gets flushed instead of a >> timeout, since that approach reads more correct given the >> specification. And really it's just about literally calling a >> subroutine to flush everything when the in_progress bit is set to >> completed, and removing the code from "access on" >> >> If you're interested to do what I've just described, I don't think >> you'll get any push-back. >> >> Patrick >> >> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley >> <david.j.cobbley@linux.intel.com> wrote: >>> >>> I noticed that when using ipmitool lan set <channel> <parameter>, the >>> openbmc stack does not apply the settings. This seems like a non-standard >>> implementation. While using ipmitool as the standard is not quite >>> correct, >>> customers do expect it to work. >>> >>> After sending any sort of lan set command with ipmitool, the changes >>> don't >>> appear to stick and this message shows up in the journal: >>> "Use Set Channel Access command to apply" >>> >>> I know IPMI 2.0 is a little ambiguous about implementation specifics, but >>> I >>> believe the intention was to utilize the "Set In Progress" bit (Parameter >>> 0) >>> while doing work, and use "Set Complete" when you are finished to flush >>> the >>> changes. >>> >>> To work around ipmitool constantly setting and unsetting the "Set In >>> Progress" bit in between every parameter applied, some BMC stacks >>> accumulate >>> network changes over a period of time and apply after a timeout - this is >>> also compatible with ipmitool's non-standard use of the "Set In Progress" >>> bit. >>> >>> >>> Is there a plan to circle back and change this functionality to work with >>> ipmitool in the future? >>> >>> Thanks, >>> -Dave Cobbley >>> > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-02-14 20:32 ` Patrick Venture @ 2018-02-14 20:53 ` Vernon Mauery 2018-03-13 15:36 ` Tom Joseph 0 siblings, 1 reply; 9+ messages in thread From: Vernon Mauery @ 2018-02-14 20:53 UTC (permalink / raw) To: Patrick Venture; +Cc: Dave Cobbley, OpenBMC Maillist On 14-Feb-2018 12:32 PM, Patrick Venture wrote: >I thought you had to explicitly set in_progress with the ipmitool? My >own ipmitool utility is implemented as you described where it doesn't >assume anything about your intent, just follows the actions. Currently, ipmitool (incorrectly) sets the "set in progress" bit for every lan configuration parameter it sets. Given how the CLI interface only allows the user to specify a single parameter at a time, it might be smart to have ipmitool also expose controls for the "set in progress" bit. Alternately, providing a way to to specify multiple parameters in a single call would be good. Something like: ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1 dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp and it would automatically set and use the set in progress bit correctly. And ipmid could then take two actions, depending on how this bit is (ab)used: 1) if only a single command is wrapped up in the set-in-progress/set-complete, then employ a timeout so that after some amount of time, all the queued commands get applied. 2) if multiple commands get wrapped up in the set-in-progress/set-complete, then apply the command set when the set-complete is received. Getting ipmitool changed to have correct behavior will take some doing, so we will need to be able to deal with its incorrect behavior for now. But also responding to correct behavior can make tools that employ that behavior work even better (with no timeout delays). Just my $0.02. --Vernon >There's definitely the possibility of thrashing. > >On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley ><david.j.cobbley@linux.intel.com> wrote: >> Do you have any concerns about ipmitool constantly flushing the network as >> it sets & unsets the complete bit inbetween parameters, >> i.e. if you are setting 4 different parameters from a script? >> >> I'm not sure if this brings a lot of thrashing to the to the ipmi network >> stack or network manager. >> >> Seems like it would be prudent to fix ipmitool upstream to allow you to set >> multiple parameters, in addition to the ipmi stack. >> >> >>> I personally have found this non-standard implementation a bit >>> unpleasant, as it requires using a different command to basically >>> flush it. I am planning to implement it such that setting in progress >>> before and complete after is how it all gets flushed instead of a >>> timeout, since that approach reads more correct given the >>> specification. And really it's just about literally calling a >>> subroutine to flush everything when the in_progress bit is set to >>> completed, and removing the code from "access on" >>> >>> If you're interested to do what I've just described, I don't think >>> you'll get any push-back. >>> >>> Patrick >>> >>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley >>> <david.j.cobbley@linux.intel.com> wrote: >>>> >>>> I noticed that when using ipmitool lan set <channel> <parameter>, the >>>> openbmc stack does not apply the settings. This seems like a non-standard >>>> implementation. While using ipmitool as the standard is not quite >>>> correct, >>>> customers do expect it to work. >>>> >>>> After sending any sort of lan set command with ipmitool, the changes >>>> don't >>>> appear to stick and this message shows up in the journal: >>>> "Use Set Channel Access command to apply" >>>> >>>> I know IPMI 2.0 is a little ambiguous about implementation specifics, but >>>> I >>>> believe the intention was to utilize the "Set In Progress" bit (Parameter >>>> 0) >>>> while doing work, and use "Set Complete" when you are finished to flush >>>> the >>>> changes. >>>> >>>> To work around ipmitool constantly setting and unsetting the "Set In >>>> Progress" bit in between every parameter applied, some BMC stacks >>>> accumulate >>>> network changes over a period of time and apply after a timeout - this is >>>> also compatible with ipmitool's non-standard use of the "Set In Progress" >>>> bit. >>>> >>>> >>>> Is there a plan to circle back and change this functionality to work with >>>> ipmitool in the future? >>>> >>>> Thanks, >>>> -Dave Cobbley >>>> >> ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-02-14 20:53 ` Vernon Mauery @ 2018-03-13 15:36 ` Tom Joseph 2018-03-21 14:49 ` Alexander Amelkin 0 siblings, 1 reply; 9+ messages in thread From: Tom Joseph @ 2018-03-13 15:36 UTC (permalink / raw) To: OpenBMC Maillist Cc: Vernon Mauery, Patrick Venture, Dave Cobbley, Ratan Gupta, Jeremy Kerr Hello, There is a patch up for applying the network settings, with this patch it would not require set channel access command to apply the changes. A timer kicks in everytime set-complete happens, and the network settings are applied once the timer expires. https://gerrit.openbmc-project.xyz/#/q/topic:2932 Regards, Tom On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote: > On 14-Feb-2018 12:32 PM, Patrick Venture wrote: >> I thought you had to explicitly set in_progress with the ipmitool? My >> own ipmitool utility is implemented as you described where it doesn't >> assume anything about your intent, just follows the actions. > > Currently, ipmitool (incorrectly) sets the "set in progress" bit for > every lan configuration parameter it sets. Given how the CLI interface > only allows the user to specify a single parameter at a time, it might > be smart to have ipmitool also expose controls for the "set in > progress" bit. Alternately, providing a way to to specify multiple > parameters in a single call would be good. Something like: > > ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1 > dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp > > and it would automatically set and use the set in progress bit correctly. > > And ipmid could then take two actions, depending on how this bit is > (ab)used: > 1) if only a single command is wrapped up in the > set-in-progress/set-complete, then employ a timeout so that after some > amount of time, all the queued commands get applied. > 2) if multiple commands get wrapped up in the > set-in-progress/set-complete, then apply the command set when the > set-complete is received. > > Getting ipmitool changed to have correct behavior will take some > doing, so we will need to be able to deal with its incorrect behavior > for now. But also responding to correct behavior can make tools that > employ that behavior work even better (with no timeout delays). > > Just my $0.02. > > --Vernon > >> There's definitely the possibility of thrashing. >> >> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley >> <david.j.cobbley@linux.intel.com> wrote: >>> Do you have any concerns about ipmitool constantly flushing the >>> network as >>> it sets & unsets the complete bit inbetween parameters, >>> i.e. if you are setting 4 different parameters from a script? >>> >>> I'm not sure if this brings a lot of thrashing to the to the ipmi >>> network >>> stack or network manager. >>> >>> Seems like it would be prudent to fix ipmitool upstream to allow you >>> to set >>> multiple parameters, in addition to the ipmi stack. >>> >>> >>>> I personally have found this non-standard implementation a bit >>>> unpleasant, as it requires using a different command to basically >>>> flush it. I am planning to implement it such that setting in progress >>>> before and complete after is how it all gets flushed instead of a >>>> timeout, since that approach reads more correct given the >>>> specification. And really it's just about literally calling a >>>> subroutine to flush everything when the in_progress bit is set to >>>> completed, and removing the code from "access on" >>>> >>>> If you're interested to do what I've just described, I don't think >>>> you'll get any push-back. >>>> >>>> Patrick >>>> >>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley >>>> <david.j.cobbley@linux.intel.com> wrote: >>>>> >>>>> I noticed that when using ipmitool lan set <channel> <parameter>, the >>>>> openbmc stack does not apply the settings. This seems like a >>>>> non-standard >>>>> implementation. While using ipmitool as the standard is not quite >>>>> correct, >>>>> customers do expect it to work. >>>>> >>>>> After sending any sort of lan set command with ipmitool, the changes >>>>> don't >>>>> appear to stick and this message shows up in the journal: >>>>> "Use Set Channel Access command to apply" >>>>> >>>>> I know IPMI 2.0 is a little ambiguous about implementation >>>>> specifics, but >>>>> I >>>>> believe the intention was to utilize the "Set In Progress" bit >>>>> (Parameter >>>>> 0) >>>>> while doing work, and use "Set Complete" when you are finished to >>>>> flush >>>>> the >>>>> changes. >>>>> >>>>> To work around ipmitool constantly setting and unsetting the "Set In >>>>> Progress" bit in between every parameter applied, some BMC stacks >>>>> accumulate >>>>> network changes over a period of time and apply after a timeout - >>>>> this is >>>>> also compatible with ipmitool's non-standard use of the "Set In >>>>> Progress" >>>>> bit. >>>>> >>>>> >>>>> Is there a plan to circle back and change this functionality to >>>>> work with >>>>> ipmitool in the future? >>>>> >>>>> Thanks, >>>>> -Dave Cobbley >>>>> >>> > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-03-13 15:36 ` Tom Joseph @ 2018-03-21 14:49 ` Alexander Amelkin 2018-03-22 21:57 ` Emily Shaffer 0 siblings, 1 reply; 9+ messages in thread From: Alexander Amelkin @ 2018-03-21 14:49 UTC (permalink / raw) To: openbmc [-- Attachment #1.1: Type: text/plain, Size: 5961 bytes --] Just my 2 cents. I did previously some commits to the ipmitool project, and can tell that fixing ipmitool upstream now doesn't seem feasible as the only active project maintainer (Zdenek Styblik) has called it quits about a year ago. I've tried asking him to make me an admin of the project he doesn't want to maintain anymore, but he just stopped responding. I'm thinking about forking off (actually did it to YADRO organization on github) and starting to maintain our own version of ipmitool. That however doesn't solve the problem as the original ipmitool is a part of all the available Linux distros, and making their maintainers switch to our version I anticipate to be hell of a quest... Applying the changes with a timeout after the set-complete looks good to me as it both follows the specification and allows for addressing the incorrect behavior of the original ipmitool. Alexander. 13.03.2018 18:36, Tom Joseph wrote: > Hello, > > There is a patch up for applying the network settings, with this patch > it would not require set channel access command to apply the changes. > A timer kicks in everytime set-complete happens, and the network > settings are applied once the timer expires. > > https://gerrit.openbmc-project.xyz/#/q/topic:2932 > > Regards, > Tom > > On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote: >> On 14-Feb-2018 12:32 PM, Patrick Venture wrote: >>> I thought you had to explicitly set in_progress with the ipmitool? My >>> own ipmitool utility is implemented as you described where it doesn't >>> assume anything about your intent, just follows the actions. >> >> Currently, ipmitool (incorrectly) sets the "set in progress" bit for >> every lan configuration parameter it sets. Given how the CLI >> interface only allows the user to specify a single parameter at a >> time, it might be smart to have ipmitool also expose controls for the >> "set in progress" bit. Alternately, providing a way to to specify >> multiple parameters in a single call would be good. Something like: >> >> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1 >> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp >> >> and it would automatically set and use the set in progress bit >> correctly. >> >> And ipmid could then take two actions, depending on how this bit is >> (ab)used: >> 1) if only a single command is wrapped up in the >> set-in-progress/set-complete, then employ a timeout so that after >> some amount of time, all the queued commands get applied. >> 2) if multiple commands get wrapped up in the >> set-in-progress/set-complete, then apply the command set when the >> set-complete is received. >> >> Getting ipmitool changed to have correct behavior will take some >> doing, so we will need to be able to deal with its incorrect behavior >> for now. But also responding to correct behavior can make tools that >> employ that behavior work even better (with no timeout delays). >> >> Just my $0.02. >> >> --Vernon >> >>> There's definitely the possibility of thrashing. >>> >>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley >>> <david.j.cobbley@linux.intel.com> wrote: >>>> Do you have any concerns about ipmitool constantly flushing the >>>> network as >>>> it sets & unsets the complete bit inbetween parameters, >>>> i.e. if you are setting 4 different parameters from a script? >>>> >>>> I'm not sure if this brings a lot of thrashing to the to the ipmi >>>> network >>>> stack or network manager. >>>> >>>> Seems like it would be prudent to fix ipmitool upstream to allow >>>> you to set >>>> multiple parameters, in addition to the ipmi stack. >>>> >>>> >>>>> I personally have found this non-standard implementation a bit >>>>> unpleasant, as it requires using a different command to basically >>>>> flush it. I am planning to implement it such that setting in >>>>> progress >>>>> before and complete after is how it all gets flushed instead of a >>>>> timeout, since that approach reads more correct given the >>>>> specification. And really it's just about literally calling a >>>>> subroutine to flush everything when the in_progress bit is set to >>>>> completed, and removing the code from "access on" >>>>> >>>>> If you're interested to do what I've just described, I don't think >>>>> you'll get any push-back. >>>>> >>>>> Patrick >>>>> >>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley >>>>> <david.j.cobbley@linux.intel.com> wrote: >>>>>> >>>>>> I noticed that when using ipmitool lan set <channel> <parameter>, >>>>>> the >>>>>> openbmc stack does not apply the settings. This seems like a >>>>>> non-standard >>>>>> implementation. While using ipmitool as the standard is not quite >>>>>> correct, >>>>>> customers do expect it to work. >>>>>> >>>>>> After sending any sort of lan set command with ipmitool, the changes >>>>>> don't >>>>>> appear to stick and this message shows up in the journal: >>>>>> "Use Set Channel Access command to apply" >>>>>> >>>>>> I know IPMI 2.0 is a little ambiguous about implementation >>>>>> specifics, but >>>>>> I >>>>>> believe the intention was to utilize the "Set In Progress" bit >>>>>> (Parameter >>>>>> 0) >>>>>> while doing work, and use "Set Complete" when you are finished to >>>>>> flush >>>>>> the >>>>>> changes. >>>>>> >>>>>> To work around ipmitool constantly setting and unsetting the "Set In >>>>>> Progress" bit in between every parameter applied, some BMC stacks >>>>>> accumulate >>>>>> network changes over a period of time and apply after a timeout - >>>>>> this is >>>>>> also compatible with ipmitool's non-standard use of the "Set In >>>>>> Progress" >>>>>> bit. >>>>>> >>>>>> >>>>>> Is there a plan to circle back and change this functionality to >>>>>> work with >>>>>> ipmitool in the future? >>>>>> >>>>>> Thanks, >>>>>> -Dave Cobbley >>>>>> >>>> >> > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-03-21 14:49 ` Alexander Amelkin @ 2018-03-22 21:57 ` Emily Shaffer 2018-03-23 13:07 ` Alexander Amelkin 0 siblings, 1 reply; 9+ messages in thread From: Emily Shaffer @ 2018-03-22 21:57 UTC (permalink / raw) To: Alexander Amelkin; +Cc: openbmc [-- Attachment #1: Type: text/plain, Size: 6926 bytes --] FWIW - OpenBMC does seem to have a fork of ipmitool... I don't think we've done much to it. https://github.com/openbmc/ipmitool 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. 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. On Wed, Mar 21, 2018 at 7:55 AM Alexander Amelkin <a.amelkin@yadro.com> wrote: > Just my 2 cents. > > I did previously some commits to the ipmitool project, and can tell that > fixing ipmitool upstream now doesn't seem feasible as the only active > project maintainer (Zdenek Styblik) has called it quits about a year > ago. I've tried asking him to make me an admin of the project he doesn't > want to maintain anymore, but he just stopped responding. > > I'm thinking about forking off (actually did it to YADRO organization on > github) and starting to maintain our own version of ipmitool. That > however doesn't solve the problem as the original ipmitool is a part of > all the available Linux distros, and making their maintainers switch to > our version I anticipate to be hell of a quest... > > Applying the changes with a timeout after the set-complete looks good to > me as it both follows the specification and allows for addressing the > incorrect behavior of the original ipmitool. > > Alexander. > > > 13.03.2018 18:36, Tom Joseph wrote: > > Hello, > > > > There is a patch up for applying the network settings, with this patch > > it would not require set channel access command to apply the changes. > > A timer kicks in everytime set-complete happens, and the network > > settings are applied once the timer expires. > > > > https://gerrit.openbmc-project.xyz/#/q/topic:2932 > > > > Regards, > > Tom > > > > On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote: > >> On 14-Feb-2018 12:32 PM, Patrick Venture wrote: > >>> I thought you had to explicitly set in_progress with the ipmitool? My > >>> own ipmitool utility is implemented as you described where it doesn't > >>> assume anything about your intent, just follows the actions. > >> > >> Currently, ipmitool (incorrectly) sets the "set in progress" bit for > >> every lan configuration parameter it sets. Given how the CLI > >> interface only allows the user to specify a single parameter at a > >> time, it might be smart to have ipmitool also expose controls for the > >> "set in progress" bit. Alternately, providing a way to to specify > >> multiple parameters in a single call would be good. Something like: > >> > >> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway 1.2.0.1 > >> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp > >> > >> and it would automatically set and use the set in progress bit > >> correctly. > >> > >> And ipmid could then take two actions, depending on how this bit is > >> (ab)used: > >> 1) if only a single command is wrapped up in the > >> set-in-progress/set-complete, then employ a timeout so that after > >> some amount of time, all the queued commands get applied. > >> 2) if multiple commands get wrapped up in the > >> set-in-progress/set-complete, then apply the command set when the > >> set-complete is received. > >> > >> Getting ipmitool changed to have correct behavior will take some > >> doing, so we will need to be able to deal with its incorrect behavior > >> for now. But also responding to correct behavior can make tools that > >> employ that behavior work even better (with no timeout delays). > >> > >> Just my $0.02. > >> > >> --Vernon > >> > >>> There's definitely the possibility of thrashing. > >>> > >>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley > >>> <david.j.cobbley@linux.intel.com> wrote: > >>>> Do you have any concerns about ipmitool constantly flushing the > >>>> network as > >>>> it sets & unsets the complete bit inbetween parameters, > >>>> i.e. if you are setting 4 different parameters from a script? > >>>> > >>>> I'm not sure if this brings a lot of thrashing to the to the ipmi > >>>> network > >>>> stack or network manager. > >>>> > >>>> Seems like it would be prudent to fix ipmitool upstream to allow > >>>> you to set > >>>> multiple parameters, in addition to the ipmi stack. > >>>> > >>>> > >>>>> I personally have found this non-standard implementation a bit > >>>>> unpleasant, as it requires using a different command to basically > >>>>> flush it. I am planning to implement it such that setting in > >>>>> progress > >>>>> before and complete after is how it all gets flushed instead of a > >>>>> timeout, since that approach reads more correct given the > >>>>> specification. And really it's just about literally calling a > >>>>> subroutine to flush everything when the in_progress bit is set to > >>>>> completed, and removing the code from "access on" > >>>>> > >>>>> If you're interested to do what I've just described, I don't think > >>>>> you'll get any push-back. > >>>>> > >>>>> Patrick > >>>>> > >>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley > >>>>> <david.j.cobbley@linux.intel.com> wrote: > >>>>>> > >>>>>> I noticed that when using ipmitool lan set <channel> <parameter>, > >>>>>> the > >>>>>> openbmc stack does not apply the settings. This seems like a > >>>>>> non-standard > >>>>>> implementation. While using ipmitool as the standard is not quite > >>>>>> correct, > >>>>>> customers do expect it to work. > >>>>>> > >>>>>> After sending any sort of lan set command with ipmitool, the changes > >>>>>> don't > >>>>>> appear to stick and this message shows up in the journal: > >>>>>> "Use Set Channel Access command to apply" > >>>>>> > >>>>>> I know IPMI 2.0 is a little ambiguous about implementation > >>>>>> specifics, but > >>>>>> I > >>>>>> believe the intention was to utilize the "Set In Progress" bit > >>>>>> (Parameter > >>>>>> 0) > >>>>>> while doing work, and use "Set Complete" when you are finished to > >>>>>> flush > >>>>>> the > >>>>>> changes. > >>>>>> > >>>>>> To work around ipmitool constantly setting and unsetting the "Set In > >>>>>> Progress" bit in between every parameter applied, some BMC stacks > >>>>>> accumulate > >>>>>> network changes over a period of time and apply after a timeout - > >>>>>> this is > >>>>>> also compatible with ipmitool's non-standard use of the "Set In > >>>>>> Progress" > >>>>>> bit. > >>>>>> > >>>>>> > >>>>>> Is there a plan to circle back and change this functionality to > >>>>>> work with > >>>>>> ipmitool in the future? > >>>>>> > >>>>>> Thanks, > >>>>>> -Dave Cobbley > >>>>>> > >>>> > >> > > > > > [-- Attachment #2: Type: text/html, Size: 9671 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: IPMI Set LAN Configuration Parameters 2018-03-22 21:57 ` Emily Shaffer @ 2018-03-23 13:07 ` Alexander Amelkin 0 siblings, 0 replies; 9+ messages in thread From: Alexander Amelkin @ 2018-03-23 13:07 UTC (permalink / raw) To: Emily Shaffer; +Cc: openbmc [-- Attachment #1.1.1: Type: text/plain, Size: 8382 bytes --] 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. Thanks for pointing to the openbmc ipmitool repo. Alexander. 23.03.2018 00:57, Emily Shaffer wrote: > FWIW - OpenBMC does seem to have a fork of ipmitool... I don't think > we've done much to it. https://github.com/openbmc/ipmitool > > 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. > > 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. > > On Wed, Mar 21, 2018 at 7:55 AM Alexander Amelkin <a.amelkin@yadro.com > <mailto:a.amelkin@yadro.com>> wrote: > > Just my 2 cents. > > I did previously some commits to the ipmitool project, and can > tell that > fixing ipmitool upstream now doesn't seem feasible as the only active > project maintainer (Zdenek Styblik) has called it quits about a year > ago. I've tried asking him to make me an admin of the project he > doesn't > want to maintain anymore, but he just stopped responding. > > I'm thinking about forking off (actually did it to YADRO > organization on > github) and starting to maintain our own version of ipmitool. That > however doesn't solve the problem as the original ipmitool is a > part of > all the available Linux distros, and making their maintainers > switch to > our version I anticipate to be hell of a quest... > > Applying the changes with a timeout after the set-complete looks > good to > me as it both follows the specification and allows for addressing the > incorrect behavior of the original ipmitool. > > Alexander. > > > 13.03.2018 18:36, Tom Joseph wrote: > > Hello, > > > > There is a patch up for applying the network settings, with this > patch > > it would not require set channel access command to apply the > changes. > > A timer kicks in everytime set-complete happens, and the network > > settings are applied once the timer expires. > > > > https://gerrit.openbmc-project.xyz/#/q/topic:2932 > > > > Regards, > > Tom > > > > On Thursday 15 February 2018 02:23 AM, Vernon Mauery wrote: > >> On 14-Feb-2018 12:32 PM, Patrick Venture wrote: > >>> I thought you had to explicitly set in_progress with the > ipmitool? My > >>> own ipmitool utility is implemented as you described where it > doesn't > >>> assume anything about your intent, just follows the actions. > >> > >> Currently, ipmitool (incorrectly) sets the "set in progress" > bit for > >> every lan configuration parameter it sets. Given how the CLI > >> interface only allows the user to specify a single parameter at a > >> time, it might be smart to have ipmitool also expose controls > for the > >> "set in progress" bit. Alternately, providing a way to to specify > >> multiple parameters in a single call would be good. Something like: > >> > >> ipmitool lan set 1 ipaddr 1.2.3.4 netmask 255.255.0.0 gateway > 1.2.0.1 > >> dns 1.2.1.1 ipmitool lan set 1 ipsrc dhcp > >> > >> and it would automatically set and use the set in progress bit > >> correctly. > >> > >> And ipmid could then take two actions, depending on how this bit is > >> (ab)used: > >> 1) if only a single command is wrapped up in the > >> set-in-progress/set-complete, then employ a timeout so that after > >> some amount of time, all the queued commands get applied. > >> 2) if multiple commands get wrapped up in the > >> set-in-progress/set-complete, then apply the command set when the > >> set-complete is received. > >> > >> Getting ipmitool changed to have correct behavior will take some > >> doing, so we will need to be able to deal with its incorrect > behavior > >> for now. But also responding to correct behavior can make tools > that > >> employ that behavior work even better (with no timeout delays). > >> > >> Just my $0.02. > >> > >> --Vernon > >> > >>> There's definitely the possibility of thrashing. > >>> > >>> On Wed, Feb 14, 2018 at 11:16 AM, Dave Cobbley > >>> <david.j.cobbley@linux.intel.com > <mailto:david.j.cobbley@linux.intel.com>> wrote: > >>>> Do you have any concerns about ipmitool constantly flushing the > >>>> network as > >>>> it sets & unsets the complete bit inbetween parameters, > >>>> i.e. if you are setting 4 different parameters from a script? > >>>> > >>>> I'm not sure if this brings a lot of thrashing to the to the ipmi > >>>> network > >>>> stack or network manager. > >>>> > >>>> Seems like it would be prudent to fix ipmitool upstream to allow > >>>> you to set > >>>> multiple parameters, in addition to the ipmi stack. > >>>> > >>>> > >>>>> I personally have found this non-standard implementation a bit > >>>>> unpleasant, as it requires using a different command to > basically > >>>>> flush it. I am planning to implement it such that setting in > >>>>> progress > >>>>> before and complete after is how it all gets flushed instead > of a > >>>>> timeout, since that approach reads more correct given the > >>>>> specification. And really it's just about literally calling a > >>>>> subroutine to flush everything when the in_progress bit is > set to > >>>>> completed, and removing the code from "access on" > >>>>> > >>>>> If you're interested to do what I've just described, I don't > think > >>>>> you'll get any push-back. > >>>>> > >>>>> Patrick > >>>>> > >>>>> On Wed, Feb 14, 2018 at 9:14 AM, Dave Cobbley > >>>>> <david.j.cobbley@linux.intel.com > <mailto:david.j.cobbley@linux.intel.com>> wrote: > >>>>>> > >>>>>> I noticed that when using ipmitool lan set <channel> > <parameter>, > >>>>>> the > >>>>>> openbmc stack does not apply the settings. This seems like a > >>>>>> non-standard > >>>>>> implementation. While using ipmitool as the standard is not > quite > >>>>>> correct, > >>>>>> customers do expect it to work. > >>>>>> > >>>>>> After sending any sort of lan set command with ipmitool, > the changes > >>>>>> don't > >>>>>> appear to stick and this message shows up in the journal: > >>>>>> "Use Set Channel Access command to apply" > >>>>>> > >>>>>> I know IPMI 2.0 is a little ambiguous about implementation > >>>>>> specifics, but > >>>>>> I > >>>>>> believe the intention was to utilize the "Set In Progress" bit > >>>>>> (Parameter > >>>>>> 0) > >>>>>> while doing work, and use "Set Complete" when you are > finished to > >>>>>> flush > >>>>>> the > >>>>>> changes. > >>>>>> > >>>>>> To work around ipmitool constantly setting and unsetting > the "Set In > >>>>>> Progress" bit in between every parameter applied, some BMC > stacks > >>>>>> accumulate > >>>>>> network changes over a period of time and apply after a > timeout - > >>>>>> this is > >>>>>> also compatible with ipmitool's non-standard use of the "Set In > >>>>>> Progress" > >>>>>> bit. > >>>>>> > >>>>>> > >>>>>> Is there a plan to circle back and change this functionality to > >>>>>> work with > >>>>>> ipmitool in the future? > >>>>>> > >>>>>> Thanks, > >>>>>> -Dave Cobbley > >>>>>> > >>>> > >> > > > > [-- Attachment #1.1.2: Type: text/html, Size: 13050 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-03-23 13:07 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-14 17:14 IPMI Set LAN Configuration Parameters Dave Cobbley 2018-02-14 18:32 ` Patrick Venture 2018-02-14 19:16 ` Dave Cobbley 2018-02-14 20:32 ` Patrick Venture 2018-02-14 20:53 ` Vernon Mauery 2018-03-13 15:36 ` Tom Joseph 2018-03-21 14:49 ` Alexander Amelkin 2018-03-22 21:57 ` Emily Shaffer 2018-03-23 13:07 ` Alexander Amelkin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.