Added control for interface failover on IPMI

[jcpunk]

These additions control IPMI device failover (at least on my systems). I've only got SuperMicro IPMI so I'm unclear how these commands respond on other IPMI devices.

[petems]

This might be better as a case statement:

  case $interface_type {
    'dedicated': {
      # code
    }
    'shared': {
      # code
    }
    'failover': {
      # code
    }
    default: {
      fail('Unknown interface_type')
    }
  }

[jcpunk]

That does look nicer, I've updated my code and pushed a new commit.

[jhoblitt]

@jcpunk What brand of BMC are you working with? Let me see if I can dig up my notes on SM oem commands.

[elisiano]

He's using supermicro and we also have some of those.
I can confirm that in the past I had to run the same command (after reading the docs: http://www.supermicro.com/support/faqs/faq.cfm?faq=9829 )

[jhoblitt]

It looks like I have been using ipmitool raw 0x30 0x70 0x0c 1 1 but I'm unsure if this is translatable across different vendors.

[ripclawffb]

I've tried this on Dell and I get errors. Maybe this can be an optional parameter? Or we could make a ipmi_raw defined type where you provide the raw command and expected output that way you can run any raw command.

On Tue, Jul 12, 2016 at 7:31 AM -0700, "Joshua Hoblitt" notifications@github.com wrote:

It looks like I have been using ipmitool raw 0x30 0x70 0x0c 1 1 but I'm unsure if this is translatable across different vendors.

---

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#28 (comment)

[jhoblitt]

I'm OK with merging something SM specific but would request that there is a code comment calling this out. It shouldn't be very hard to add a fact with a BMC vendor ID to add support for additional brands with the interface in this PR.

Of course, this might be easier to handle in a native type.

[jhoblitt]

@ripclawffb Sort of surprisingly, I don't have bare metal access to a modern Dell. Do you know if interface switching can be done via oem commands or is a Dell specific utility required?

[jcpunk]

For building an abstraction for raw commands, a native type does sound rational.

While it would directly benefit me, I'm nervous about adding things that don't work everywhere....

[ripclawffb]

Here's a cheat sheet that seems to work on the Dell. I just tested and verified.

http://www.theprojectbot.com/ipmitool-cheatsheet-and-configuring-drac-from-ipmitool/

Change the NIC settings to dedicated
#ipmitool raw 0x30 0x24 2
Change the NIC settings to shared
#ipmitool raw 0x30 0x24 0
Check the NIC settings
#ipmitool raw 0x30 0x25

[jcpunk]

Adding additional bits to the fire, it looks like ipmitool on some releases (1.8.17) supports ipmitool lan get which may take care of this.... Alas others do not (el6, el7)

[jhoblitt]

I realize it has been awhile... is this still a desired feature?

[jcpunk]

I'm still interested in some version of this behavior.

[jhoblitt]

I think I'm willing to accept this as exec statements but there needs to be some sort of guard logic to make sure raw commands aren't run on the wrong flavor of BMC.

[jcpunk]

In theory I've rebased this off HEAD and gotten the tests sorted. In practice, I can't seem to run the unit tests locally.... I get a weird ruby error.

[jcpunk]

hmmm not sure why those tests are failing....

[jcpunk]

I've rebased off HEAD with an updated module sync.