IPMI API Endpoints - Ironic and Maas

[jarrod-lowe]

Does anyone know if this covers enough of IPMI to work with Ironic and/or MaaS (Metal-as-a-Service)?

[seffyroff]

It doesn't implement any IPMI endpoints as far as I know. It's on my list to have a go at hacking that in, when I get a moment :)

[spyd3rweb]

Unfortunately it doesn't actually implement an IPMI interface; I actually bought everything to use diy-ipmi with Openstack Ironic, before I realized this. I do plan on creating an ironic-staging-driver that can at least be used to turn on and off a computer/server using the SainSmart Web Relay api (https://www.sainsmart.com/products/network-web-server-16-channels-relay-ethernet-controller-module-remote-control-board-lan-wan-web-server-rj45-port). It should be pretty straight forward for someone to implement the api within diy-ipmi.

[Fmstrat]

Can you point me to documentation for IPMI endpoints and identify the most important ones? I can have a look at the complexity.

[spyd3rweb]

@Fmstrat @jl-1 and I would like to utilize diy-ipmi as a power_interface for Openstack Ironic's ipmitool driver (https://docs.openstack.org/ironic/latest/admin/drivers/ipmitool.html).

Even though it would likely be way easier just to write a custom ironic staging driver to work directly with the SainSmart Web Relay, I'd be more interested in helping out with implementing the ipmitool driver support within diy-ipmi, as the ipmitool driver is deployed with Ironic by default. Fortunately, folks don't need to install Ironic to test, and all you need is the widely available ipmitool itself. If anyone does wish to look into using Ironic, I'd first recommend looking into Bifrost (https://docs.openstack.org/kolla-ansible/latest/reference/bifrost.html).

The full spec of IPMI 2.0 is insane (https://www.intel.com/content/www/us/en/servers/ipmi/ipmi-second-gen-interface-spec-v2-rev1-1.html), but again all we really need is ipmi power state support. Fortunately there is already a python based ipmisim server (https://github.com/rhtyd/ipmisim) which could likely be heavily leveraged; (https://github.com/CJLove/ipmisim) has an update for multiple sessions from same IP.

A design decision will have to be made on how we specify between multiple servers. Normally there's an ipmi address per server, but we'll likely only have a single interface on the Pi3, unless we use sub-interfaces/vlan sorcery. I feel like there is two likely options:

• Use the same ipmi_address and a unique username and password to specify between multiple servers
• Utilize the same ipmi_local_address, the ipmi_bridging (single) option, and use the target_channel/address (as seen on the ironic ipmitool driver page) to specify between multiple servers.

[Srendi]

+1 for theforeman. My opinion on addressing is to use subinterfaces on the rpi with a unique ip address for each target in the same broadcast domain.

[spyd3rweb]

I feel like there is two likely options:

• Use the same ipmi_address and a unique username and password to specify between multiple servers
• Utilize the same ipmi_local_address, the ipmi_bridging (single) option, and use the target_channel/address (as seen on the ironic ipmitool driver page) to specify between multiple servers.

@jl-1 @Srendi Sorry, I should have published/posted this earlier: pypmi

For my use case I began implementing an Intelligent Platform Management Bridge (PMB), a single networked host running an extended version of pyghmi, which allows for bridging up to 255 custom Baseboard Management Controllers (BMC).