| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Up until now plugin options were defined via tuples, with positional
significance of the tuple elements. This made plugin option creation
fairly easy, but option handling could easily become confusing.
Instead, create a new `PluginOpt` class that plugin options from here on
out will need to build from in order to function. These will still be
applied to plugins by inserting them into the `option_list` class attr
in order to retain an easy way to expand plugin options for authors.
Internally, options are now assigned to a dict which is then directly
accessed for plugin option manipulations. PluginOpt default values are
retained separate from their current value, and elements are assigned
directly to meaningful identifiers within the class. This should
alleviate some of the overhead when handling plugin options within sos.
Not all current tuple elements have been carried over into the new
`PluginOpt` class - for example, the 'speed' attribute has been dropped
as it does not have a current function. In the planned `sos info`
component, the time effects of a plugin option should be documented in
the `long_desc` attribute instead.
Additionally, the `Plugin.get_option_as_list()` method has been removed
as it was not being used anywhere.
Note that this particular commit only introduces the new class, and the
loading options used by `SoSReport()`. As such, plugins using options
currently will report errors during test runs. A commit following this
one will shuffle existing plugin options into the new class structure
and allow the plugins to execute normally.
Resolves: #274
Resolves: #452
Resolves: #1597
Signed-off-by: Jake Hunsaker <jhunsake@redhat.com>
|
