| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| | |
Fix kernel[:modules] on :darwin
|
| | | |
|
| | | |
|
| |\ \
| | |
| | | |
catch and ignore failure to load chef
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
if chef version is 11.8.2 and it pins ohai to <~ 6.0, then if we
install ohai 7, the chef plugin will attempt to load chef up and
then will puke hard since ohai 7 is already loaded. this just skips
chef version detection if that dependency resolution problem occurs.
|
| |\ \ \
| |/ /
|/| | |
send log output to STDERR by default
|
| |/ /
| |
| |
| |
| | |
mixing up JSON output with STDOUT warnings and errors is guaranteed to
annoy all the people.
|
| |\ \
| |/
|/| |
|
| |/
|
|
|
|
|
|
| |
The previous logic instantiated plugins as the files were read. This
caused multiple instances of plugins to be created when a plugin is
"reopened" in another file.
Additionally, loading-specific logic is moved from System to Loader.
|
| |\ |
|
| |/
|
|
|
|
|
|
|
|
| |
This greatly speeds up running ohai from the command line when given a
set of attributes to display (like `ohai ec2`). Prior to this patch,
ohai would run all plugins and then filter out the data. With this
patch, ohai only runs relevant plugins.
As an unscientific test `bin/ohai network` on my laptop takes ~4s
without this patch compared to ~1.1s with the patch.
|
| |\
| |
| |
| | |
See OHAI-545
|
| |/
|
|
|
| |
This works around an incompatibility between bundler, rubygems 2.2.0,
and ruby 1.8.7.
|
| |\
| |
| | |
OC-10250
|
| | | |
|
| | |
| |
| |
| | |
syntax errors
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
In any case, this wasn't going to work, but may leave this plugin
non-functional on Solaris2. We need to work out how a platform-specific
collect_data block can call the default one when needed to make this
plugin work correctly again.
|
| |/ |
|
| |\
| |
| | |
when a plugin depends on an attribute that doesn't have a provider, look for providers in parent attribute(s) and pick those to run instead.
|
| | |
| |
| |
| | |
find_closest_providers_for to look for a parent attribute that actually has providers, create new error Ohai::Exceptions::ProviderNotFound to indicate when an attribute exists in the mapping but doesn't have any listed providers
|
| | |
| |
| |
| | |
methods
|
| | | |
|
| | |
| |
| |
| | |
providers in parent attribute(s)
|
| |\ \
| |/
|/| |
Add spec test to check the platform specific collect_data check.
|
| |/ |
|
| |\
| |
| | |
OC-10251: Comments and minor changes for Nitpicks
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
Refactor the runner class.
Make sure require_plugin() checks v6 plugins first.
Use partial paths as keys in the v6 dependency solver.
|
| |\
| |
| |
| |
| | |
Add whitelist attributes run mode option to Ohai::System API. Integrating with
CLI will be done in a follow-up patch.
|
| |/
|
|
|
|
|
|
|
| |
* `Ohai::System#all_plugins` takes an option whitelist filter
* `Ohai::ProvidesMap#find_providers_for` now finds all plugins at the
specified nesting or deeper. For example, if a plugin provides
"virtualization/networks" and no plugin provides "virtualization",
then find_providers_for(["virtualization"]) would return `[nil]`. It
now finds all providers deeper than the specified level in the map.
|
| |\
| |
| | |
OC-9924 - Recursively search plugin_path directories for plugins
|
| | |
| |
| |
| | |
done as a separate PR in order to keep this PR small.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
done in a single PR :(
1-) VersionVI and VersionVII classes are moved to their own classes.
2-) VersionVII class only gets the data instead of full System object.
3-) A new integration testing infrastructure is started (similar to Chef integration tests).
4-) Loader code is refactored.
5-) New integration tests for Loader are added.
|
| |/ |
|
| |\
| |
| | |
Clean up `jenkins_run_tests.bat`
|
| |/
|
|
| |
This change ensures the bat file is in sync with what we have in
opscode/chef.
|
| |\
| |
| |
| | |
Extract a class to maintain the provided attributes to providing plugins mapping
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The name "attributes" to refer to the map of attributes<->plugins
providing attributes was confusing because it was inaccurate and often
used near a local variable named "attributes" containing a very
different kind of data (such as an Array of strings referring to
attributes another plugin depended on). Renaming to "provides_map"
clears up the confusion.
|
| | |
| |
| |
| |
| | |
Only test code was accessing this, modified to use the public API of the
class.
|
| | |
| |
| |
| |
| |
| | |
Also eliminates redundant tests in other classes that primarily test
ProvidesMap behavior. Higher-level tests have been left in place to
verify the interaction of the components.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Code to map a plugin to the attributes it provides or look up a plugin
by provided attributes was located in different parts of the code base
where it operated directly on the underlying data structure. Extracting
to a class lets us access the information we want using domain specific
terminology so things are easier to understand.
|
| | | |
|
| |/ |
|
