Bug 1001383

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