Add extra_plugin_paths setting which gets populated from WA_PLUGIN_PATHS
environment variable. This allows specifying additional locations to
scan for WA plugins.
Ensure that boot and runtime parameters always get initialized to an
obj_dict even when not explicitly specified. This will ensure they get
serialized and deserialized properly.
Catch exceptions raised when attempting to set value of a config point,
and re-raise as ConfigError with name associated with the value in the
config file.
- RebootPolicy: correctly handle being passed another instance of
RebootPolicy on creation; this a requirement for it to be usable as a
ConfigurationPoint kind.
- RebootPolicy: move static method to above __init__ (consistency).
- RunConfiguration: handle deserialization of 'device_config' entry.
- RunConfiguration: move static method to above __init__ (consistency).
Add support for loading plugins from packages that register themselves
with WA by writing their names into $WA_USER_DIRECTORY/packages.
This is functionality that existed in WA2 and was omitted in WA3 until
now.
Uses os.eviron as the default environment for creation of a
MetaConfiguration object, this allows an instance to be created without
providing any parameters and fixes re-creating an instance from pod.
--diable can now be used to disable both intruments and
result_processors from the command line (overriding configuration
files). Rename variable names to reflect this.
Replace update_enabled_instruments with update_augmentations, which
correctly splits instruments and results processors from augmentations
configuration values.
While instruments and processors are now handled uniformly in
configuration, they still need to be handled differently during actual
execution. This is the point where they get split again.
Remllace merge_instruments_result_processors with merge_agumentations
which is updated to properly merge the new unified "augmentations"
configurations.
Rename ConfigurationPoint "instrumenation" to "augmentations". Unlike
WA2, in W3, instruments and result_porcessors are handled identically in
configuration (though there're still distinct pulgin types).
"instrumentation" and "result_porcessors" entries in configuration are
now aliases for the same configuration point, which is renamed to
"augmentations" to reflect the fact that it contains both types of
plugins.
Expose PluginLoader's get_plugin_class via PluginCache. PluginCache is
basically intented to act like a PluginLoader, except when instantiating
plugins, the "default" parameter values are taken form the cached
configruation, rather than the actual defaults defined in the Plugin's
parmaters.
This maintains the default behaviour of bailing out immediately if any workload
fails in initialize(), but adds a setting, bail_on_init_failure, to change this
behaviour optionally. This can be useful where WA is being used more as a batch
processor.
Currently if you get confused and write a config with something like:
energy_measurement:
acme_cape
Then you get an error when we try to 'iteritems' on the value
'acme_cape'. Instead, explicitly check for this case.
