Forge Home

hprcu

Manage HP server BIOS settings

10,719 downloads

10,412 latest version

3.5 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.0.2 (latest)
  • 0.0.1
released Dec 12th 2013

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'tobyriddell-hprcu', '0.0.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add tobyriddell-hprcu
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install tobyriddell-hprcu --version 0.0.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.

Download
Tags: hardware, bios, hp, hprcu

Documentation

tobyriddell/hprcu — version 0.0.2 Dec 12th 2013

puppet-hprcu

Puppet type & provider to modify BIOS of HP servers using hprcu

Usage

puppet resource hprcu

puppet apply -e "hprcu{ 'default': intelrhyperthreadingoptions = 'Enabled' }"

In a manifest:

In a class:

Notes:

  • There's only one collection of BIOS settings per host so there's only one hprcu resource per host, and its name is 'default'.
  • Property names must conform to the Puppet grammar, as defined in grammar.ra in the Puppet source. Thus 'Intel (R) Hyperthreading Options' is represented by 'intelrhyperthreadingoptions'.
  • You may want to run this code (and therefore hprcu) only when required - running hprcu may interfere with reading the realtime clock from the CMOS (see footnote 4 here: http://mjg59.dreamwidth.org/25686.html)

Regenerating lib/puppet/type/hprcu.rb

It may be necessary to regenerate the Ruby code for the provider if new BIOS settings are added or names change. Here's an example of how to do this:

Dependencies

This code requires Gregoire Lejeune's ruby-xslt: https://github.com/glejeune/ruby-xslt

Design choices

It would be ideal to have a single type for managing BIOS settings for multiple vendors' hardware, and a provider per-vendor to manage resource properties for each particular vendor platform. However, the target is slowly moving: vendors have different names for the same BIOS setting, BIOS revisions can change property names ('name-creep'), new hardware may introduce new settings. Owing to the fact that Puppet doesn't support dynamic property names (see http://grokbase.com/t/gg/puppet-dev/1254htyrr9/how-to-allow-user-specified-property-names-in-provider-code) the names of properties must be pre-defined.

One option would be to map between a setting (e.g. C-states) and a well-defined name, but there are drawbacks to this approach:

  • what to do it a setting is only supported by HP and not Oracle (for example)
  • if a setting's name changes the mappings would need updating

These considerations have led me to implement a type & provider for HP hardware. The hprcu utility is used under the hood to query and change settings. In order to make life easier in the face of name-creep, the code for the type can be regenerated automatically using XML output from hprcu (the provider doesn't contain any hard-coded property names and therefore shouldn't need to be changed so often). This auto-generation may also be needed to support different BIOS revisions that have different names for settings.

Because property names are auto-generated they can be non-intuitive, for example 'intelrhyperthreadingoptions' instead of plain 'hyperthreading'. As mentioned above, I don't want to have to maintain a static mapping and hence have chosen not to use more friendly names. Running 'puppet resource hprcu' on a server is a good way to determine the name of the relevant property.