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.
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.
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.
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> 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> Date: Mon Sep 8 14:59:56 2014 -0400 (cherry picked from commit 8ae962204cbd503a7937076721b916ff83b8b5f0) Signed-off-by: Jay Shaughnessy <jshaughn>
Larry, if you agree this API method addresses the need then i think you can close this BZ.
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?
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> 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> Date: Tue Sep 9 10:51:46 2014 -0400 (cherry picked from commit c5eb7d6e97f8149ec91ba13569eee7306d35c956) Signed-off-by: Jay Shaughnessy <jshaughn>
Moving to ON_QA as available to test with latest brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=396547
documentation updated, changes visible under release notes as well. Screen-shots attached.
Created attachment 959340 [details] doc_release_notes
Created attachment 959341 [details] getResourceConfiguration-3.3
Created attachment 959342 [details] getResourceConfiguration_3.2_vs_3.3