Bug 815899 - Resource configuration unavailable using remote API after import
Resource configuration unavailable using remote API after import
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Configuration (Show other bugs)
4.4
Unspecified Unspecified
high Severity urgent (vote)
: ---
: JON 3.1.0
Assigned To: Lukas Krejci
Mike Foley
:
Depends On:
Blocks: jon310-sprint11/rhq44-sprint11 822880
  Show dependency treegraph
 
Reported: 2012-04-24 14:34 EDT by Lukas Krejci
Modified: 2013-09-03 11:17 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 822880 (view as bug list)
Environment:
Last Closed: 2013-09-03 11:17:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lukas Krejci 2012-04-24 14:34:53 EDT
Description of problem:
The issue is that latest configuration update might be out of sync with the resource configuration directly referenced from the resource.

The consequences are quite severe. The resource configuration returned from the remote API calls is empty until there is an explicit user-initiated update of the resource configuration or the agent detects an out-of-band configuration update.

This happens if the configuration of the resource is viewed from the GUI prior to the first configuration report for the resource being sent up from the agent (which is by default 15 minutes after import).

Version-Release number of selected component (if applicable):
4.4.0-SNAPSHOT

How reproducible:
always

Steps to Reproduce:
1. Import RHQ Agent or any resource with non-empty resource configuration
2. Directly after import, go to its configuration tab. Check that it contains correct configuration properties.
3. In CLI, do:
ProxyFactory.getResource(<RESOURCE_ID_OF_THE_IMPORTED_RESOURCE).resourceConfiguration.properties
4. Alternatively in the CLI do:
ConfigurationManager.getResourceConfiguration(<RESOURCE_ID_OF_THE_IMPORTED_RESOURCE>).properties
  
Actual results:
The CLI claims that the configuration has "0 rows", i.e. no properties, which is in direct contrast to what can be seen using the GUI

Expected results:
CLI returns the same configuration as can be seen in the GUI

Additional info:
My initial investigation suggests that the culprit for this bug is ConfigurationManagerBean.getLatestResourceConfigurationUpdate() (line 359) which at a point calls (at line 427) persistNewAgentReportedResourceConfiguration() (line 466) method (which does persist an update in the configuration history but merely sets the resource configuration on the resource (line 489), leaving it upon the callers to merge the resource in (or let the entity manager do that on transaction commit). After the persistNewAgentReportedResourceConfiguration() has been called, getLatestResourceConfigurationUpdate() then checks (line 443) if there has been any changes reported by the persistNewAgentReportedResourceConfiguration() and if there were, it DISCARDS any pending changes in the entityManager by calling entityManager.clear() (line 451).

This in effect prevents the resource configuration to be set to a correct value by any future configuration report from the agent up to the point where the configuration actually changes either by user-initiated update through RHQ or by agent detecting a change. This is because in ConfigurationServerServiceImpl.persistUpdatedResourceConfiguration() we return eagerly if we detect that the configuration hasn't changed from the last known update (which was successfully persisted by the above call-chain, unlike the reference to the current resource configuration from the resource itself).
Comment 1 Mike Foley 2012-04-30 11:38:27 EDT
per BZ triage ccrouch, loleary, mfoley
Comment 2 Charles Crouch 2012-04-30 12:39:41 EDT
Check if this is a regression from JON3.0.1, if not, push to JON3.1.1
Comment 3 Libor Zoubek 2012-05-17 09:48:12 EDT
Not a regression from JON3.0.1, but I've run into this BZ when verifying bug 801638. Anyone trying to use add-as7-standalone-server-to-cluster.js sample right after importing one of AS7 servers will fail running this script.
Comment 4 Mike Foley 2012-05-17 10:27:47 EDT
per Libor's comment, this needs to be in 3.1 to allow 801638 to work.
changing target release to 3.1
Comment 5 Lukas Krejci 2012-05-18 11:51:33 EDT
release/jon3.1.x http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=85f7920eb79ad999623beda1fc5408e39f96d29c
Author: Lukas Krejci <lkrejci@redhat.com>
Date:   Fri May 18 13:43:21 2012 +0200

    [BZ 822880] - Make sure to NOT discard any pending DB changes before
    masking the configuration.
    (cherry picked from commit 43770f14dd308618f47b4d2940366cb86082aef0)
Comment 6 Lukas Krejci 2012-05-18 12:11:40 EDT
Note that the change only specifically fixes the errorneous state where the configuration would NEVER be attached to the resource if the user viewed the resource's configuration in the GUI prior to agent sending the first configuration report.

It DOES NOT make sure that the resource's configuration is available instantly after import using the standard remote API calls. The resource configuration attached to the resource represents the "last known" configuration and we make no guarantees about it being available - the "raw" remote API therefore shouldn't be changed in any way for that.

The ProxyFactory, though, being our convenience wrapper around resource, could be enhanced to overcome that limitation (and use the same method calls as the GUI does to fetch the live config from the agent if no last known config has been fetched yet). I created a separate RFE bug 822968 for that.
Comment 7 Heiko W. Rupp 2013-09-03 11:17:38 EDT
Bulk closing of old issues in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.