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:
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.
(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
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.
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.
this is to be considered done now. if you want to remove a bundle completely, you use the purge feature now.
*** Bug 647815 has been marked as a duplicate of this bug. ***
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.
Bulk closing of issues that were VERIFIED, had no target release and where the status changed more than a year ago.