[15:32] <@cswiii> a nice consequence of the config change detection feature is that if you've mucked around with the conf 
                  file manually and you fatfinger a value -- say, "max_connections = 200o" -- bringing it up in the UI 
                  immediately indicates any bad values, akin to if a user tried to enter them from within the UI.
[15:32] <@cswiii> built-in config file debugging.
[15:34] <@cswiii> just realise it brings up a question, however -- should users be able to revert back to a config that 
                  doesn't parse, i.e., has known, bad value(s)?  I'm not sure i can answer that.

[...]

[15:37] <@cswiii> i'm just wondering if we should allow users -- or warn users -- if the config file they are trying to go 
                  back to is known to have bad values.
[15:37] <@cswiii> maybe a warn in the UI or something
[15:37] <@cswiii> a little "bomb" icon :)
[15:39] < joseph> we should probably disallow rolling back to a configuration update that failed
[15:39] < mazz> we can probably do that in the UI simple enough - if status is failed, don't render checkbox
[15:39] < joseph> though, changes made agent-side will always come across as success
[15:39] < joseph> even if there is an error in them
[15:39] < mazz> true dat
[15:39] <@cswiii> joseph: yeah, it's kind of an edge case
[15:40] <@cswiii> but people might be fickle, "I don't /care/ that it was broken, i made those changes, I want to be able to 
                  go back and examine those changes /I/ made!"
[15:40] <@cswiii> i dunno tho ugh

I think this works how it should. If the previous config change failed for external reasons, then the current functionality has a nice way to retry the change.

ghinkle, agreed, let's not limit functionality like that on the off-chance that they do want to re-attempt something that failed.  for instance, a failure might be due to that agent being down.  this is not a failure of the values in the update, but a failure at the comm layer, and that user might want to retry the update with the same values.  allowing rollbacks to any config as opposed to constraining the list is prudent.

This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1216