Bug 535817 (RHQ-2474) - Config change conflict detection does not work with RHQ Agent config
Summary: Config change conflict detection does not work with RHQ Agent config
Keywords:
Status: CLOSED NOTABUG
Alias: RHQ-2474
Product: RHQ Project
Classification: Other
Component: Configuration
Version: 1.3
Hardware: All
OS: All
medium
medium vote
Target Milestone: ---
: ---
Assignee: John Mazzitelli
QA Contact: Sunil Kondkar
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks: rhq4
TreeView+ depends on / blocked
 
Reported: 2009-10-20 16:43 UTC by Jeff Weiss
Modified: 2014-11-09 22:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
linux/postgres
Last Closed: 2011-02-21 17:04:12 UTC


Attachments (Terms of Use)

Description Jeff Weiss 2009-10-20 16:43:00 UTC
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 21:05:08 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2474


Comment 2 wes hayutin 2010-02-16 16:56:06 UTC
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 17:01:12 UTC
making sure we're not missing any bugs in rhq_triage

Comment 4 John Mazzitelli 2011-02-19 01:06:14 UTC
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 17:04:12 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.