Bug 535817 (RHQ-2474)

Summary: Config change conflict detection does not work with RHQ Agent config
Product: [Other] RHQ Project Reporter: Jeff Weiss <jweiss>
Component: ConfigurationAssignee: John Mazzitelli <mazz>
Status: CLOSED NOTABUG QA Contact: Sunil Kondkar <skondkar>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.3CC: cwelton, dajohnso, mazz
Target Milestone: ---Keywords: SubBug
Target Release: ---   
Hardware: All   
OS: All   
URL: http://jira.rhq-project.org/browse/RHQ-2474
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
linux/postgres
Last Closed: 2011-02-21 12:04:12 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 585306    

Description Jeff Weiss 2009-10-20 12:43:00 EDT
To repeat:

Go into agent prompt and in the UI go to the Agent's current config page.  Clck Edit in the config in the UI.  Now in the agent prompt, run 
> setconfig rhq.communications.remote-stream-max-idle-time-msecs=3000200

Now in the UI, change "Primary Server Switchover Check Interval" to "3600100".   Click SAVE.  Change completes successfully, the change you made in the prompt is never detected.  Expected behavior - the server should reject the change because the backing config being overwritten is not the latest configuration being edited in the UI.
Comment 1 Red Hat Bugzilla 2009-11-10 16:05:08 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2474
Comment 2 wes hayutin 2010-02-16 11:56:06 EST
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug
Comment 3 wes hayutin 2010-02-16 12:01:12 EST
making sure we're not missing any bugs in rhq_triage
Comment 4 John Mazzitelli 2011-02-18 20:06:14 EST
commit eeb0bbf

the Current subtab was not getting the live config from the agent. this new commit does this now.

still have to do some tests, i'm not sure if this commit actually fixes the issue this bz reports.
Comment 5 John Mazzitelli 2011-02-21 12:04:12 EST
OK, after reading the description more closely, I'm going to close this as "working as expected/not a bug".

What the issue is reporting is this:

1) you are viewing the current config but...
2) after the current config view was rendered, the underlying config on the remote resource itself changed and then...
3) the user saved the current config view.

This will overwrite the underlying config with the config the user sees in the current config view. And this is how it was designed to work. Whatever the user sees on the screen is the configuration that is saved. If it so happens that within that very short time frame between the user rendering the current config view and the user pressing the save button, the underlying config happened to change by some other external means, that external change is going to be thrown away and overridden by the user's new config settings.

AFAIK, we've never indicated through implementation or documentation that we have a feature where, if the user attempts to save a config, it will fail if the underlying config changed between the config view rendering time and the config view save-button-pressed time. The user will always override the remote config with the config the user actually saw and saved in the UI.