Bug 1001383 - getResourceConfiguration does not return the current resource configuration
Summary: getResourceConfiguration does not return the current resource configuration
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: CLI
Version: JON 3.1.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: CR01
: JON 3.3.0
Assignee: Jay Shaughnessy
QA Contact: Armine Hovsepyan
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-26 23:56 UTC by Larry O'Leary
Modified: 2018-12-06 15:15 UTC (History)
5 users (show)

(edit)
The Resource configuration returned by a call to getResourceConfiguration did not reflect the existing configuration on the resource. Instead, it reflected the latest configuration returned by a configuration-discovery scan. The client using the remote API or a CLI script was unable to retrieve the resource configuration for a given resource using an intuitive method. Enhancements to the ConfigurationManager.getLatestResourceConfigurationUpdate Remote API Javadoc now explain the retrieval features more intuitively.
Clone Of:
(edit)
Last Closed: 2014-12-11 14:00:38 UTC


Attachments (Terms of Use)
doc_release_notes (125.49 KB, image/png)
2014-11-20 13:25 UTC, Armine Hovsepyan
no flags Details
getResourceConfiguration-3.3 (31.03 KB, image/png)
2014-11-20 13:26 UTC, Armine Hovsepyan
no flags Details
getResourceConfiguration_3.2_vs_3.3 (109.96 KB, image/png)
2014-11-20 13:26 UTC, Armine Hovsepyan
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 450683 None None None Never

Description Larry O'Leary 2013-08-26 23:56:10 UTC
Description of problem:
Resource configuration returned by a call to getResourceConfiguration does not reflect the existing configuration on the resource. Instead, it seem to only reflect that latest configuration returned by a configuration-discovery scan. The result is that the a client using the remote API or a CLI script is unable to retrieve the resource configuration for a given resource using an intuitive method.

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

How reproducible:
Always

Steps to Reproduce:
1.  Install EAP 6 domain and add 4 server groups to it with a port offsets of 150.

        for (( i=1; i<=4; i++ )); do
            sed -i '/^.*<\/server-group>$/ {N; s/^.*<\/server-group>\n.*<\/server-groups>/        <\/server-group>\n        <server-group name="main-server-group-'"$i"'" profile="full">\n            <jvm name="default">\n                <heap size="64m" max-size="768m"\/>\n                <permgen max-size="256m"\/>\n            <\/jvm>\n            <socket-binding-group ref="full-sockets" port-offset="150"\/>\n        <\/server-group>\n    <\/server-groups>/}' ${JBOSS_HOME}/domain/configuration/domain.xml
        done

2.  Create test getMaxOffset.js CLI script:

        cat > /tmp/getMaxOffset.js << EOF
var crit = new ResourceCriteria();
crit.addFilterName("main-server-group");
crit.addFilterPluginName("JBossAS7");
crit.addFilterResourceTypeName("ServerGroup");
crit.fetchResourceConfiguration(true);
var serverGroups = ResourceManager.findResourcesByCriteria(crit);
var max_offset=0;

for (var i=0; i<serverGroups.size(); i++) {
    println("-------------------------------------------------------------------------------");
    println("Resource ID: " + serverGroups.get(i).getId() + "   Resource Name: " + serverGroups.get(i).getName());
    var current_offset = Number(serverGroups.get(i).getResourceConfiguration().getSimpleValue("socket-binding-port-offset"));
    println("Resource.getResourceConfiguration returned offset of " + current_offset);
    var current_offset = Number(ConfigurationManager.getResourceConfiguration(serverGroups.get(i).id).getSimpleValue("socket-binding-port-offset"));
    println("CM.getResourceConfiguration returned offset of " + current_offset);
}
EOF

3.  Start JON server.
4.  Configure JON agent to use 30 seconds for rhq.agent.plugins.configuration-discovery.initial-delay-secs and start it:

        sed -i '/^.*<!--.*$/{N; s/^.*<!--.*\n.*<entry key="rhq\.agent\.plugins\.configuration-discovery\.initial-delay-secs" value=".*"\/>/               <entry key="rhq.agent.plugins.configuration-discovery.initial-delay-secs" value="30"\/>\n               <!--/}' "${RHQ_AGENT_HOME}/conf/agent-configuration.xml"
        cd "${RHQ_AGENT_HOME}/bin"
        ./rhq-agent.sh --cleanconfig

5.  Wait for agent to be running for approximately 1 minute:

        sleep 1m

6.  Import agent platform into inventory.        
7.  Start EAP 6 domain.
8.  Execute a manual discovery so the EAP 6 domain is discovered.
9.  Import EAP domain into inventory.
10. Configure EAP domain resource (user/password).
11. Verify that 6 server groups have been discovered and are available.
12. Execute the getMaxOffset.js CLI script:

        ${TESTENV_DIR}/rhq-remoting-cli-4.4.0.JON312GA/bin/rhq-cli.sh -u rhqadmin -p rhqadmin -s localhost -t 7080 -f /tmp/getMaxOffset.js

Actual results:
Remote server version is: 3.1.2.GA (323587d:38819b7)
Login successful
-------------------------------------------------------------------------------
Resource ID: 10050   Resource Name: main-server-group-2
Resource.getResourceConfiguration returned offset of 0
CM.getResourceConfiguration returned offset of 0
-------------------------------------------------------------------------------
Resource ID: 10044   Resource Name: main-server-group
Resource.getResourceConfiguration returned offset of 0
CM.getResourceConfiguration returned offset of 0
-------------------------------------------------------------------------------
Resource ID: 10038   Resource Name: main-server-group-1
Resource.getResourceConfiguration returned offset of 0
CM.getResourceConfiguration returned offset of 0
-------------------------------------------------------------------------------
Resource ID: 10037   Resource Name: main-server-group-4
Resource.getResourceConfiguration returned offset of 0
CM.getResourceConfiguration returned offset of 0
-------------------------------------------------------------------------------
Resource ID: 10035   Resource Name: main-server-group-3
Resource.getResourceConfiguration returned offset of 0
CM.getResourceConfiguration returned offset of 0


Expected results:
Remote server version is: 3.1.2.GA (323587d:38819b7)
Login successful
-------------------------------------------------------------------------------
Resource ID: 10050   Resource Name: main-server-group-2
Resource.getResourceConfiguration returned offset of 150
CM.getResourceConfiguration returned offset of 150
-------------------------------------------------------------------------------
Resource ID: 10044   Resource Name: main-server-group
Resource.getResourceConfiguration returned offset of 0
CM.getResourceConfiguration returned offset of 0
-------------------------------------------------------------------------------
Resource ID: 10038   Resource Name: main-server-group-1
Resource.getResourceConfiguration returned offset of 150
CM.getResourceConfiguration returned offset of 150
-------------------------------------------------------------------------------
Resource ID: 10037   Resource Name: main-server-group-4
Resource.getResourceConfiguration returned offset of 150
CM.getResourceConfiguration returned offset of 150
-------------------------------------------------------------------------------
Resource ID: 10035   Resource Name: main-server-group-3
Resource.getResourceConfiguration returned offset of 150
CM.getResourceConfiguration returned offset of 150

Additional info:
There is a workaround as documented in https://access.redhat.com/site/solutions/450683 but I would imagine that it makes more sense for this to be intuitive and that getResourceConfiguration and explicitly fetching the resource configuration with the resource would result in the actual configuration being returned.

Comment 1 Jay Shaughnessy 2014-09-03 21:08:34 UTC
I believe this is working as expected.  There are a few Remote API methods for accessing the resource configuration.

1) ResourceManager.findResourcesByCriteria() +
   setFetchResourceConfiguration(true)

This is going to get you the latest resConfig in the DB.

2) ConfigurationManager.getResourceConfiguration()

This is going to get you the latest resConfig in the DB.

3) ConfigurationManager.getLiveResourceConfiguration()

This is going to actually go out to the agent and request the absolute latest configuration.


Option 3 is what they want here, I believe.  I think this can be closed as Not A Bug.

Comment 2 Larry O'Leary 2014-09-04 02:47:11 UTC
getLiveResourceConfiguration will only work if the resource in question is running. This is not what they want. 

What is needed is the ability to get the current configuration using the configuration manager. This would be the same as what would be done from the user-interface. For example, the user selects the resource's configuration page. When this happens, an attempt is made to retrieve the live configuration. If the live configuration is unavailable -- the resource or its agent is down -- the configuration is loaded from the DB.

It does not make sense for the caller to execute two methods each time it wants the configuration for a resource.

Comment 3 Jay Shaughnessy 2014-09-08 19:03:26 UTC
After studying the remote API a bit more I belive we have what they are looking for:

ResourceConfigurationUpdate ConfigurationManagerRemote.getLatestResourceConfigurationUpdate(Subject subject, int resourceId)

Get the most recent attainable resource configuration for the Resource with the given id. Retrieves and returns live resource configuration from the Agent, if possible. Otherwise returns the most recent server-side configuration (from the database). If the live availability differs from the server-side the database will be updated to match the live configuration. This can return null if an initial resource configuration has yet to be stored in the database and a live configuration can not be retrieved (e.g. in the case the agent or resource is down).

Parameters:
   subject  the user who wants to see the information
resourceId  a Resource id

Returns:
the current configuration (along with additional information about the configuration) for the Resource with the given id, or null if the resource's configuration is not yet initialized and its live configuration could not be determined. The configuration can be accessed via ResourceConfigurationUpdate.getConfiguration().


The 3.2 javadoc was a bit more confusing, the text above is the updated doco:

Master commit 8ae962204cbd503a7937076721b916ff83b8b5f0
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Mon Sep 8 14:59:56 2014 -0400

    Improve some ConfigurationManagerRemote javadoc, making it more clear that
    getLatestResourceConfigurationUpdate() satisifies the API request in the BZ 
    (I think).


Release/jon3.3.x commit 341503f9a6562bc1b538f4237b45bea035d7da5d
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Mon Sep 8 14:59:56 2014 -0400

    (cherry picked from commit 8ae962204cbd503a7937076721b916ff83b8b5f0)
    Signed-off-by: Jay Shaughnessy <jshaughn@redhat.com>

Comment 4 Jay Shaughnessy 2014-09-08 19:04:15 UTC
Larry, if you agree this API method addresses the need then i think you can close this BZ.

Comment 5 Larry O'Leary 2014-09-08 23:50:06 UTC
Jay, I agree that ConfigurationManager.getLatestResourceConfigurationUpdate will provide the user with what they want. This is actually the documented solution for the original reported issue. But the problem is more of the fact that as a user of the API, I am provided with what appears to be two pretty straight forward options to retrieve the configuration but neither work reliably. Therefore the API puts the user into a situation that they do not detect until it is too late.

First and foremost, if I retrieve a resource using ResourceCriteria object with fetchResourceConfiguration set to true -- or I directly call ConfigurationManager.getResourceConfiguration -- I do not actually get the configuration of the resource. 

Perhaps for 3.3 a fix should be in the JavaDocs for both of these methods so they explicitly call out what they really mean? It should warn of the inconsistent behavior depending on configuration scan state and point the user to the current method -- ConfigurationManager.getLatestResourceConfigurationUpdate -- to retrieve the resource's actual configuration. However, even then getLatestResourceConfigurationUpdate might not work either if the configuration had been changed since the last configuration update scan was performed.

For a future release, these methods should be refactored or additional options should be introduced that allow the user to either use the getResourceConfiguration method and pass arguments to force _live_, _stored_, _live if stored unavailable_, and _stored if live unavailable_ options. Additionally the ResourceCriteria object should provide similar options for the fetchResourceConfiguration method to do the same.

Let me know what you think and if I need to break these out into two separate BZs or if that is something you can take care of?

Comment 6 Jay Shaughnessy 2014-09-09 15:06:55 UTC
Larry,  I have to agree, the Javadoc for these calls was still confusing/incomplete, so I've gone back and fleshed them all out more fully.  Because the API does seem to have everything it needs I stopped short of adding or deprecating any methods.

Create an RFE for your proposed API as you see fit (for a future release). Let's keep this one for just the 3.3.0 work, which I think is covered now by the improved Javadoc, so I'm setting to MODIFIED (for CR01, when the Javadoc will hopefully have been generated. Although you are free to check out the changes in the commit).

One note - the "Criteria" methods will not support fetch of "live" resource configuration.  That's really outside of their scope; the "fetchXXX" methods are only to add optional, lazy-loaded database-stored data.


Master commit c5eb7d6e97f8149ec91ba13569eee7306d35c956
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Tue Sep 9 10:51:46 2014 -0400

    Further improve the confusing/incomplete javadoc surrounding the get/find
    configuration remote API methods.


Release/jon3.3.x commit 5c244aacdcb6ba7e53564d0622ee6ddbf1f4de69
Author: Jay Shaughnessy <jshaughn@redhat.com>
Date:   Tue Sep 9 10:51:46 2014 -0400

    (cherry picked from commit c5eb7d6e97f8149ec91ba13569eee7306d35c956)
    Signed-off-by: Jay Shaughnessy <jshaughn@redhat.com>

Comment 7 Simeon Pinder 2014-11-03 20:07:36 UTC
Moving to ON_QA as available to test with latest brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=396547

Comment 8 Armine Hovsepyan 2014-11-20 13:25:19 UTC
documentation updated, changes visible under release notes as well.
Screen-shots attached.

Comment 9 Armine Hovsepyan 2014-11-20 13:25:52 UTC
Created attachment 959340 [details]
doc_release_notes

Comment 10 Armine Hovsepyan 2014-11-20 13:26:32 UTC
Created attachment 959341 [details]
getResourceConfiguration-3.3

Comment 11 Armine Hovsepyan 2014-11-20 13:26:50 UTC
Created attachment 959342 [details]
getResourceConfiguration_3.2_vs_3.3


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