ohai should be more efficient when only displaying single attributes

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 0.5.8
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None

Description

When I run Ohai and return all attributes, it takes about 2 seconds:

$ time ohai > /dev/null

real    0m2.061s
user    0m1.540s
sys     0m0.710s

It ought to take much less time to calculate the json for only a single attribute, but it doesn't:

$ time ohai filesystem > /dev/null
real    0m2.016s
user    0m1.580s
sys     0m0.620s

It appears as if Ohai is executing all code and then filtering it down to only display the requested attribute. If this is the case, shouldn't it be possible to avoid executing code for unwanted attributes, thus speeding up Ohai in this case?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Toomas Pelberg added a comment -

It's impossible for ohai to save time because it doesn't know beforehand which plugins will be populating which attributes. Therefore it HAS to go through them all before selecting your attribute.

A valid workaround is to include only the plugins you'll need in your ohai configuration file, this can be done via the -f flag.

Show
Toomas Pelberg added a comment - It's impossible for ohai to save time because it doesn't know beforehand which plugins will be populating which attributes. Therefore it HAS to go through them all before selecting your attribute. A valid workaround is to include only the plugins you'll need in your ohai configuration file, this can be done via the -f flag.
Hide
Permalink
Kurt Yoder added a comment -

Sorry to be a pest, but "it doesn't know beforehand" contradicts "include only the plugins you'll need". The latter mechanism would satisfy the scope of the ticket, though I can find no documentation on how the "-f" flag works. The command-line help states only that -f is "A file to run Ohai against". I couldn't find a mention of this flag on the wiki either.

So if there is a mechanism that can be invoked via -f to only load a subset of plugins, it should also be possible to specify this option directly on the command line instead of via an external file. In fact, as in the example above, "ohai filesystem" should do just that: only load the "filesystem" plugin but nothing else.

Show
Kurt Yoder added a comment - Sorry to be a pest, but "it doesn't know beforehand" contradicts "include only the plugins you'll need". The latter mechanism would satisfy the scope of the ticket, though I can find no documentation on how the "-f" flag works. The command-line help states only that -f is "A file to run Ohai against". I couldn't find a mention of this flag on the wiki either. So if there is a mechanism that can be invoked via -f to only load a subset of plugins, it should also be possible to specify this option directly on the command line instead of via an external file. In fact, as in the example above, "ohai filesystem" should do just that: only load the "filesystem" plugin but nothing else.
Hide
Permalink
Toomas Pelberg added a comment -

The assumption was - that the user would know ( by looking at the source or reading the documentation? ) which plugins they'll need, as opposed to Ohai. Regarding the -f flag, it just reads in the file expecting regular ruby syntax, something like:

$ uname -morsv
Linux 2.6.32-33-generic #71-Ubuntu SMP Wed Jul 20 17:27:30 UTC 2011 x86_64 GNU/Linux
$ cat filesystem.rb 
require_plugin("linux::filesystem")
$ ohai -f /home/toomasp/filesystem.rb |head
{
  "filesystem": {
    "/dev/sda1": {
      "kb_size": "469311212",
      "kb_used": "176956920",
      "kb_available": "268514640",
      "percent_used": "40%",
      "mount": "/",
      "fs_type": "ext4",
      "mount_options": [

As you can see, there's no top-level filesystem plugin - there's also no top-level plugin which would do an require_plugin "#{os}::filesystem" - so Ohai uses all_plugins method which iterates over all the plugins available and loads them one by one. That's how you end up with the filesystem plugin being run. Ohai does not know which plugin will be providing the "filesystem" attribute, as there's no direct mapping between the plugin names/paths and the attributes that they might provide.

Granted, at one point we might end up with some mapping scheme that requires plugins to be named after the attributes they provide, but currently that's not in place. As some of the current plugins are in conflict with this naming scheme ( ip_scopes, language plugins like c, perl, php, ruby.. etc ) it'll break compatibility and obsolete a lot of cookbooks which depend on these attributes.

And no worries about being a pest, as questions like these cannot be answered unless asked in the first place. Hopefully you can see, if not agree with, my reasoning now.

Show
Toomas Pelberg added a comment - The assumption was - that the user would know ( by looking at the source or reading the documentation? ) which plugins they'll need, as opposed to Ohai. Regarding the -f flag, it just reads in the file expecting regular ruby syntax, something like: $ uname -morsv Linux 2.6.32-33-generic #71-Ubuntu SMP Wed Jul 20 17:27:30 UTC 2011 x86_64 GNU/Linux $ cat filesystem.rb require_plugin("linux::filesystem") $ ohai -f /home/toomasp/filesystem.rb |head { "filesystem": { "/dev/sda1": { "kb_size": "469311212", "kb_used": "176956920", "kb_available": "268514640", "percent_used": "40%", "mount": "/", "fs_type": "ext4", "mount_options": [ As you can see, there's no top-level filesystem plugin - there's also no top-level plugin which would do an require_plugin "#{os}::filesystem" - so Ohai uses all_plugins method which iterates over all the plugins available and loads them one by one. That's how you end up with the filesystem plugin being run. Ohai does not know which plugin will be providing the "filesystem" attribute, as there's no direct mapping between the plugin names/paths and the attributes that they might provide. Granted, at one point we might end up with some mapping scheme that requires plugins to be named after the attributes they provide, but currently that's not in place. As some of the current plugins are in conflict with this naming scheme ( ip_scopes, language plugins like c, perl, php, ruby.. etc ) it'll break compatibility and obsolete a lot of cookbooks which depend on these attributes. And no worries about being a pest, as questions like these cannot be answered unless asked in the first place. Hopefully you can see, if not agree with, my reasoning now.
Hide
Permalink
Seth Chisamore added a comment -

We can do better.

Show
Seth Chisamore added a comment - We can do better.

People

  • Assignee:
    Unassigned
    Reporter:
    Kurt Yoder
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: