Bug 743305

Summary: initial revision of a Resource's plugin config is not saved to the Resource's plugin config history
Product: [Other] RHQ Project Reporter: Ian Springer <ian.springer>
Component: Core ServerAssignee: Nobody <nobody>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 4.1CC: hbrock, hrupp, mazz
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ian Springer 2011-10-04 14:41:56 UTC 
Go to the Inventory > Connection Settings History subtab for a newly imported Resource that has one or more connection settings (i.e. plugin config props). Notice that it is empty, but it should contain one item representing the plugin config initially reported by the plugin discovery component. Now go to the Connection Settings subtab, change the value of a property, then click Save. Go back to the Connection Settings History subtab. Notice that there is one item for the update that you just made, but there is still no item for the initial revision. So there is now no record that there ever was another revision, which is bad for auditing and rollback purposes.

Note, Resource config does not suffer from this issue; we do save the initial revision of Resource configs.
Comment 2 John Mazzitelli 2011-10-05 16:53:33 UTC 
this also appears related to bug #743426 (this issue is probably why 743426 happens).

when we fix this, see if it also fixes the "orphaned config" problem that I also just found. if it doesn't, we should fix the orphan problem too.

the orphan problem is the fact that when I uninventory a resource that had a plugin config, the resource is removed, but the row in RHQ_CONFIG (and I think its related properties) are orphaned. They remain in the database but are never referred to again, they just take up space now.

I think this orphan happens here in ConfigurationManagerBean (I added the TODO to show what I think may solve this outside of any fix for this 743305 issue):

    public void completePluginConfigurationUpdate(PluginConfigurationUpdate update) {
        // use EJB3 reference to ourself so that transaction semantics are correct
        ConfigurationUpdateResponse response = configurationManager.executePluginConfigurationUpdate(update);
        Resource resource = update.getResource();

        // link to the newer, persisted configuration object -- regardless of errors
        // TODO: the old plugin configuration is getting orphaned here. I think we need to remove it like this:
        //       entityManager.remove(resource.getPluginConfiguration());
        resource.setPluginConfiguration(update.getConfiguration());