Some proposed changes to Manual Import functionality

Simeon Pinder spinder at redhat.com
Wed Apr 24 18:59:50 UTC 2013


Hi All,

After discussions with Jay, I wanted to describe some changes that I think we should make in support of 'Manual Import' functionality in the plugin container and potentially on the server side.

The issue: 
With BZ 883825 we stumbled into odd behavior while trying to test out 'Manual Import' of Tomcat instances. What wasn't immediately apparent was that those same Tomcat instances were already silently indexed by RHQ in the 'Discovery Queue'.  So that while attempting to 'Manual Import' these new instances with a new plugin configuration, the plugin container would take the information from the 'new' import and detect that we'd already had that in inventory(the auto-discovered version) and use the invalid configuration from that version. The result was that a user submitting a Manual Import with valid credentials, was getting rejected because RHQ was silently swapping in the wrong config with no credentials. While the situation just described is ugly, the wider issue is that it occurred because we were never clear about what should happen when one tries to 'Manual Import' a new resource resulting in a resource key that matches an existing resource.  Essentially such a behavior, if allowed, would result in a Resource configuration/status update which was not the original point.  

To summarize, RHQ/JON does not do enough to detect and deter when 'Manual Import' is being used to inadvertently update the state of a Resource already indexed by RHQ.  Current suggestions are to: 

i)Update the RHQ code to better detect and prevent such behavior with appropriate error messages
  - modify InventoryManager to error out when 'Manual Import' is called and an existing RHQ resource is already indexed.  The new logic should handle Resources in all InventoryStatus.* states better since changes to existing Resources should only be handled via our existing Resource update mechanism.  This means better agent side and server side logs messages when this situation is attempted in the future.  I'm also looking into throwing better UI errors after "Manual Import" attempts.  Right now we only really support Plugin Configuration exceptions(bad creds) or Plugin Container exceptions of which this doesn't fit in either category well.  

ii) update released/docs/support information to better describe this situation and workaround
 - this just means documenting this behavior and how to avoid getting into this state.  An administrator attempting to inventory resources could get into this state and it's confusing to debug/detect if auto discovery is doing it's job well.
 
iii)clarify the javadoc on the remote api documentation so that plugin developers know to not attempt to handle such unintentional updates. 
 - Trying to support 'Manual Import', without filtering out existing Resources that match the same identity, is a subtle point that we haven't gotten right in the past.  The DiscoveryBossRemote public api javadoc implies that we will handle cases where 'Manual Import' specifies a plugin config that maps to an existing resource.  We need to update this api description here to be clearer about which situations should not be handled by 'Manual Import'.  

This last point is tricky because there's no simple way to tell a plugin developers how to detect if the plugin configuration will map to an existing Resource already.  There is perhaps a CLI query that they can put together but it's not a great solution.  Logging error messages to the server and agent logs also isn't a great solution here from a CLI users standpoint.       

I think we should actively discourage this usage of 'Manual Import' that can overlap with Resource update. Are there any other opinions here? 

-Simeon


More information about the rhq-devel mailing list