Bug 749126

Summary: [config-sync] Plugin validation too restrictive
Product: [Other] RHQ Project Reporter: Lukas Krejci <lkrejci>
Component: Core ServerAssignee: Lukas Krejci <lkrejci>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: high    
Version: 4.2CC: ccrouch, hrupp, loleary
Target Milestone: ---   
Target Release: RHQ 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-01 10:07:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 745494    

Description Lukas Krejci 2011-10-26 09:34:07 UTC 
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 11:20:58 UTC 
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 11:27:43 UTC 
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 23:22:34 UTC 
Reset target for RHQ project.
Comment 4 Heiko W. Rupp 2013-09-01 10:07:28 UTC 
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.