This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 645412 - Request ability to revert deployments back all the way
Request ability to revert deployments back all the way
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Provisioning (Show other bugs)
3.0.0
All All
high Severity medium (vote)
: ---
: ---
Assigned To: John Mazzitelli
Mike Foley
: FutureFeature
: 647815 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-21 09:27 EDT by dsteigne
Modified: 2013-09-02 03:24 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-02 03:24:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description dsteigne 2010-10-21 09:27:13 EDT
Description of problem:
Currently, if there are versions 1.0,2.0,3.0 of the bundle. 1.0 being the first version. In this case the maximum version we can roll-back to is 1.0

Would like the ability to rollback to version before 1.0 ie version before first version of the bundle 1.0 is deployed.

Version-Release number of selected component (if applicable):
2.4

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 John Mazzitelli 2010-10-21 09:35:36 EDT
perhaps this could easily be implemented by adding a new method to BundleFacet:

BundleFacet.purge(BundlePurgeRequest request)

where this purges everything in the destination directory. This should also purge the hidden .rhqdeployments content - this API should remove everything RHQ related as well as the content it previously copied down.
Comment 2 John Mazzitelli 2010-12-23 13:03:42 EST
(In reply to comment #1)
> perhaps this could easily be implemented by adding a new method to BundleFacet:
> 
> BundleFacet.purge(BundlePurgeRequest request)
> 
> where this purges everything in the destination directory. This should also
> purge the hidden .rhqdeployments content - this API should remove everything
> RHQ related as well as the content it previously copied down.

also have to worry about backed up files. its possible the current live deployment had collisions that it backed up - we'll need to revert those backed up files to get back to the original state prior to the first deployment. and that's an ant bundle specific thing. but we need to know which bundle type we are reverting to know which plugin to talk to
Comment 3 John Mazzitelli 2011-01-24 15:39:39 EST
More commits are pushed. This is how the feature currently works and what I think is still needed:

First, this new feature is called "purge" because removes all files the last deployment laid down. If its an ant recipe (which is the more common of the two types of bundles), this means we delete all external raw files as well as the full deployment directory (and all its subdirectories).

This is not technically a full-rollback - because it is possible some other files existed in the original deploy dir and were backed up. However, if that is the case and you want to retain those original files, you can still do a step-by-step revert back from the live deployment back to version 1 and then you can purge. But you rarely will actually need to do this (as opposed to doing just a purge) because normally a deployment really just created a new deployment directory and put everything in there (i.e. there were no original files that got backed up that need to be restored after the purge).

If the deployment did not ask to manage the deploy dir (e.g. if deploying a EAR or WAR to JBossAS's /deploy directory, we don't fully manage /deploy) then we need to make sure we don't fully purge the deploy dir. This is not currently what happens, I need to write code so purge doesn't blow away the entire deploy dir - it needs to only delete files/subdirs that the deployment laid down.
Comment 4 John Mazzitelli 2011-01-25 08:51:04 EST
Pushed more code that checks to see if the deploy dir is fully managed - if it is, we purge the deploy dir fully. If not, we just remove files we put in the deploy dir - if we put subdirs in the deploy dir, we purge them completely.
Comment 5 John Mazzitelli 2011-01-26 10:55:02 EST
this is to be considered done now.

if you want to remove a bundle completely, you use the purge feature now.
Comment 6 John Mazzitelli 2011-03-24 10:10:14 EDT
*** Bug 647815 has been marked as a duplicate of this bug. ***
Comment 7 Sunil Kondkar 2011-06-24 06:19:35 EDT
Verified on build#158 (Version: 4.1.0-SNAPSHOT Build Number: c1539ab)

The purge feature removed all the contents in the deployment directory. It displays a message in UI as 'You successfully purged the bundle destination [testdest] from all of the remote machines.'

Marking as verified.
Comment 8 Heiko W. Rupp 2013-09-02 03:24:55 EDT
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.

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