Red Hat Bugzilla – Full Text Bug Listing
|Summary:||reverting a deployment fails if the deployment was more than the second one|
|Product:||[Other] RHQ Project||Reporter:||John Mazzitelli <mazz>|
|Component:||Core UI||Assignee:||John Mazzitelli <mazz>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Mike Foley <mfoley>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-09-02 03:27:38 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:||702390|
Description John Mazzitelli 2011-05-06 16:01:16 EDT
Reverting a deployment is failing if trying to revert a #3 or higher deployment. Replicate: 1) Deploy a bundle (deployment #1) 2) Deploy another version of the bundle to the same destination (#2) 3) Deploy a third version of the bundle to the same destination (#3) 4) Revert the last deployment (going from #3 -> #2). This succeeds 5) Revert again (going from #2 to #1). This fails and the error message and on screen wizard information is screwed up. The wizard's "previous deployment" information is pointing to data from a completely differerent destination (as if the IDs got mismatched). The error message says there was no previous deployment (which we know there was)
Comment 1 John Mazzitelli 2011-05-09 17:02:15 EDT
commit 310d34c - makes sure we assign the proper "replacedBundle" ID when reverting so we can revert back multiple times.
Comment 2 John Mazzitelli 2011-05-10 12:55:18 EDT
turns out the fix for this that was committed to master required the fix for bug #702390 because it sets the value which was a BundleDeployment but is now an Integer
Comment 3 John Mazzitelli 2011-05-10 18:08:45 EDT
cherry picked over to release-4.0.0 branch - f905896
Comment 4 Sunil Kondkar 2011-05-13 08:13:04 EDT
Verified on rhq401 build#25 (Version: 4.0.1-SNAPSHOT Build Number: 2267ccb) Deployed a bundle with three versions to the same destination. The revert from #3 -> #2 and the revert from #2 to #1 is successful. The revert wizard's "previous deployment" information is pointing to data from the correct destination when reverting from #2 to #1. Marking as verified.
Comment 5 Heiko W. Rupp 2013-09-02 03:27:38 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.