Red Hat Bugzilla – Bug 749126
[config-sync] Plugin validation too restrictive
Last modified: 2013-09-01 06:07:28 EDT
Description of problem:
Currently, the importers require to validate the deployed agent plugins. This validation is done using the name, version and md5 hash of the plugins.
Including the md5 hash is too restrictive, because it prevents the import to function after a simple code patch is applied to any of the plugins. This would then prevent "archivation" of the export files because they would not be usable after any update to the plugins.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create and save an export file from the CLI using SynchronizationManager.exportAllSubsystems()
2. unpack the plugin jar of one of the agent plugins
3. create an empty file at the root of the unpacked plugin (for example by executing "touch validation.test")
4. repack the plugin jar with the new file included
5. Deploy the changed plugin to a second RHQ server
6. Connect to the second RHQ server using CLI
7. Try to import the export file
plugin validation fails
The import should work because we changed no metadata
We maybe should think about removing the plugin validation altogether (at least for now) because all it does is that it makes sure that the metric template import is "safe" in the way that we can safely expect there to be the same resource types available in the source and target RHQ installs. By making the import more robust by just ignoring the non-existent resource types / metrics we could maybe get away with having no plugin validation at all.
[BZ 749126] - Loosening validation requirements on import.
This commit is quite big due to the refactoring but does only
a couple of simple things:
1) The SynchronizationManagerRemote.importAllSubsystems now returns
an ImportReport which contains the notes from subsystem importers about
"interesting" events during the import. This is used to report warnings
or other info to the caller of the import.
Namely the MetricTemplateImporter now reports all the metric templates
from the export file that were not present in the target database
(which basically means that source and target RHQ install had different
2) Import is lenient about unknown validator classes (this is to not choke
on "old" import files that still may be perfectly valid).
3) The former ConsistencyValidator has been split into 2 separate concepts:
ConsistencyValidator - persists its config into the export file, checks
the consistency of the target RHQ install as a whole.
EntityValidator - configured by the importer, does NOT persist anything
into the export file, used to validate individual entities in the export
file before the import begins.
4) Some new unit tests and a couple of simple changes in the code to
support better testability.
5) DeployedAgentPluginsValidator was "decommissioned" but left in
the codebase as an example implementation.
Some more notes:
As mentioned in the commit message, the remote API changed and the SynchronizationManager.importAllSubsystems() method now returns an ImportReport instance which contains a map of import notes per importer.
The metric template importer fills this report with all the metric templates it found in the export file that don't exist in the database during the import. These metric templates can't be imported because there is no resource type in the target RHQ install that would declare them.
Also with this fix, the export file no longer contains ANY "validator" elements because all the validations are done on the individual entity level.
There are a couple of validation checks:
* System Settings:
1) at most 1 entity present in the export file
2) SystemManagerRemote.validateSystemConfiguration() passes with the data from the export file
* Metric Templates:
1) no duplicate entries present in the export file (i.e. no two metricTemplate elements in the export file that would have the same plugin, resource type and metric template name).
Reset target for RHQ project.
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.