Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Config change conflict detection does not work with RHQ Agent config|
|Product:||[Other] RHQ Project||Reporter:||Jeff Weiss <jweiss>|
|Component:||Configuration||Assignee:||John Mazzitelli <mazz>|
|Status:||CLOSED NOTABUG||QA Contact:||Sunil Kondkar <skondkar>|
|Version:||1.3||CC:||cwelton, dajohnso, mazz|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-02-21 12:04:12 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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.