Bug 534418 - (RHQ-1216) disallow rolling back to a configuration update unless it had SUCCESS state
disallow rolling back to a configuration update unless it had SUCCESS state
Product: RHQ Project
Classification: Other
Component: Configuration (Show other bugs)
All All
low Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
: Improvement
Depends On:
  Show dependency treegraph
Reported: 2008-12-04 15:40 EST by Joseph Marques
Modified: 2009-02-25 00:25 EST (History)
0 users

See Also:
Fixed In Version: 1.2
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joseph Marques 2008-12-04 15:40:00 EST

Comment 1 Corey Welton 2008-12-04 15:44:57 EST
[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
Comment 2 Greg Hinkle 2009-02-04 17:29:29 EST
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.
Comment 3 Joseph Marques 2009-02-25 00:25:15 EST
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.
Comment 4 Red Hat Bugzilla 2009-11-10 15:28:16 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1216

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