Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[config-sync] Plugin validation too restrictive|
|Product:||[Other] RHQ Project||Reporter:||Lukas Krejci <lkrejci>|
|Component:||Core Server||Assignee:||Lukas Krejci <lkrejci>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Version:||4.2||CC:||ccrouch, hrupp, loleary|
|Target Release:||RHQ 4.4.0|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-01 06:07:28 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Lukas Krejci 2011-10-26 05:34:07 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): 4.2.0-SNAPSHOT How reproducible: always 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 Actual results: plugin validation fails Expected results: The import should work because we changed no metadata Additional info: 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.
Comment 1 Lukas Krejci 2011-11-07 06:20:58 EST
release_jon3.x: 7fbb3fcdadbec68b5fe1dc4b1fec66954fce9c88 master: f3f7a0535ce7f62bd1c0ddd85bd1d24a835fc446 [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 plugins installed). 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.
Comment 2 Lukas Krejci 2011-11-07 06:27:43 EST
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).
Comment 3 Larry O'Leary 2012-11-27 18:22:34 EST
Reset target for RHQ project.
Comment 4 Heiko W. Rupp 2013-09-01 06:07:28 EDT
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.