I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?(‘has_ipmi’)
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information’
ipmi true
save_hint(‘has_ipmia’)
else
ipmi false
end
On Sep 23, 2013, at 9:36 AM, Graham Christensen graham@grahamc.com wrote:
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present?
Normally, I would recommend storing this information in a node attribute that gets saved back to the server, but I don't think any of those attributes would be available to you during the earliest part of the Chef run -- like when Ohai is trying to discover what's on the machine.
So, failing the node attribute solution, I don't see a better alternative than caching this information in a local hint file on the node.
Another idea would be to set it as a persistent node attribute (node.set), then you can use the attribute? helper method and adopt similar logic that you have below. Now you can keep search and still avoid the overhead of calling dmidecode repeatedly.
On September 23, 2013 at 10:37:23 AM, Graham Christensen (graham@grahamc.com) wrote:
Hello everyone,
I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?(‘has_ipmi’)
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information’
ipmi true
save_hint(‘has_ipmia’)
else
ipmi false
end
Hrmm… Yes, that would work as well. Originally I was going to implement this as an Ohai plugin which wouldn't have the node.set available to it,but as an early-stage recipe may work just fine. Although, that would mean I couldn't use ohai in system scripts.
If IPMI is not present, it appears it runs in less than half a second, so re-running it repeatedly on a host without it would cause no harm.
On Monday, September 23, 2013 at 9:57 AM, Tim Green wrote:
Another idea would be to set it as a persistent node attribute (node.set), then you can use the attribute? helper method and adopt similar logic that you have below. Now you can keep search and still avoid the overhead of calling dmidecode repeatedly.
On September 23, 2013 at 10:37:23 AM, Graham Christensen (graham@grahamc.com (mailto://graham@grahamc.com)) wrote:
Hello everyone,
I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?('has_ipmi')
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information'
ipmi true
save_hint('has_ipmia')
else
ipmi false
end
Based on this then, I suspect the time this could take is highly variable. Is it bad form to create a hint file from within an ohai plugin? just essentially echo '{"detected": false}' > /etc/chef/ohai/hints/ipmi.json or echo '{"detected": true}' > /etc/chef/ohai/hints/ipmi.json after the first detection?
That seems really odd that it's taking 30 seconds for you. On my Supermicro systems that command takes less than a second. Might be worth seeing if there are any IPMI firmware updates to apply from SM.
Tim Smith - Systems Engineer
m: +1 707.738.8132
On Sep 23, 2013, at 7:36 AM, Graham Christensen graham@grahamc.com wrote:
Hello everyone,
I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?('has_ipmi')
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information'
ipmi true
save_hint('has_ipmia')
else
ipmi false
end
On Monday, September 23, 2013 at 11:16 AM, Tim Smith wrote:
That seems really odd that it's taking 30 seconds for you. On my Supermicro systems that command takes less than a second. Might be worth seeing if there are any IPMI firmware updates to apply from SM.
Tim Smith - Systems Engineer
m: +1 707.738.8132
I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?('has_ipmi')
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information'
ipmi true
save_hint('has_ipmia')
else
ipmi false
end
Not to mention it appears dmidecode is run via Ohai regardless.
On Monday, September 23, 2013 at 9:16 AM, Tim Smith wrote:
That seems really odd that it's taking 30 seconds for you. On my Supermicro systems that command takes less than a second. Might be worth seeing if there are any IPMI firmware updates to apply from SM.
Tim Smith - Systems Engineer
m: +1 707.738.8132
I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?('has_ipmi')
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information'
ipmi true
save_hint('has_ipmia')
else
ipmi false
end
I suppose then it doesn't matter! However, the dmi plugin doesn't provide any useful regarding the IPMI device, and a secondary call to dmidecode is necessary, unless it caches it somewhere in memory, and not as a node attribute (I don't see it doing that.)
On Monday, September 23, 2013 at 9:16 AM, Tim Smith wrote:
That seems really odd that it's taking 30 seconds for you. On my Supermicro systems that command takes less than a second. Might be worth seeing if there are any IPMI firmware updates to apply from SM.
Tim Smith - Systems Engineer
m: +1 707.738.8132
I maintain a deployment of SuperMicro servers, and Dell servers, as well as a compliment of cloud machines. What I want to accomplish is as follows:
An ohai plugin to determine if IPMI is available. I can do this with dmidecode, which takes about 30 seconds:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
And the failure mode, takes less than one second:
sudo dmidecode --type 38
dmidecode 2.11
No SMBIOS nor DMI entry point found, sorry.
Unfortunately it takes too long to run on a regular basis. (If anyone has sage wisdom on detecting IPMI in a quicker fashion, it would be appreciated.) Would it be a faux pas to touch a hint file after the first run which indicates it is present? The logic might look like this:
if hint?('has_ipmi')
ipmi true
else if dmidecode --type 38.include? 'IPMI Device Information'
ipmi true
save_hint('has_ipmia')
else
ipmi false
end
It is perfectly fine to cache the results of slow computations such as IPMI
detection where the results are extremely unlikely to change over the
cache's lifetime. The ohai hints directory is a great place for ohai
plugins to use as a cache. Since this is the non-default course of action,
however, document what is being cached and why so that your successor (or
you in six months) is not surprised.
Cheers,
Jay Feldblum
On Mon, Sep 23, 2013 at 11:52 AM, Graham Christensen graham@grahamc.comwrote:
Based on this then, I suspect the time this could take is highly variable.
Is it bad form to create a hint file from within an ohai plugin? just
essentially echo '{"detected": false}' > /etc/chef/ohai/hints/ipmi.json
or echo '{"detected": true}' > /etc/chef/ohai/hints/ipmi.json after the
first detection?
On Mon, Sep 23, 2013 at 10:36 AM, Graham Christensen graham@grahamc.com wrote:
sudo dmidecode --type 38
dmidecode 2.11
SMBIOS 2.6 present.
Handle 0x2600, DMI type 38, 18 bytes
IPMI Device Information
Interface Type: KCS (Keyboard Control Style)
Specification Version: 2.0
I2C Slave Address: 0x10
NV Storage Device: Not Present
Base Address: 0x0000000000000CA8 (I/O)
Register Spacing: 32-bit Boundaries
The existing Ohai DMI plugin can capture this. It has a whitelist of
which types to include (OHAI-260 [1]), you'll need to add type 38 to
the whitelist. See here: