Description of problem:
After deploying a mix of Patch Bundles and 1-off patches, Purge of the "Live" deployed bundle failed. From JON CLI, "patch rollback" was successful.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Deploy mixed bundles (mix of Patch Bundles and 1-off's) to EAP
2. Purge "Live" patch bundle (in this case it was a Purge of 6.2.3 bundle)
Purge should not fail.
Created attachment 934144 [details]
This is going to be a bit difficult.
The implemented purge behavior doesn't support a "piecewise" rollback too well (piecewise in the sense that 6.2.3 patch bundle really is 6.2.1 + 6.2.2 + 6.2.3 but in the described situation we only want rollback 6.2.3 patch, but in other situations rolling back 6.2.2 or even 6.2.1 would be the expected behavior).
After thinking about it, I think we can implement proper purge behavior if we store a little bit of metadata about patch deployment externally but this is a little bit of work that is going to take me some time.
I'll leave this BZ targeted to ER03 for the moment but that may be pushed further.
Changed how revert and purge works to be more inline with the expectations of JON's bundle subsystem user:
[BZ 1136945] Purge/revert of EAP patch bundles works more sanely.
To implement this reasonably, we started tracking the state of
patch bundles deployed through RHQ in external file, located under
the target Wildfly/EAP server's .installation/.rhq subdirectory (the
.installation directory is used by Wfly/EAP itself to keep track of
patching, so it is a logical place to add patching related information).
During deployment we determine the effective set of patches that were
applied from the patch file (by comparing histories before and after
deployment). We then use this information to revert/purge only the
patches that were deployed using RHQ. This information is stored per
destination in the above mentioned metadata directory (so that multiple
destinations per EAP are supported (even though such arrangement is
In another words all patches applied before a first patch bundle was
deployed through a destination are retained after a bundle purge and
the revert or purge of the bundle will fail or warn if the history
of patch deployment is unexpected (due to external patch rollbacks
The revert/purge will fail if no patches can be rolled back due
to the state of the history having a different "tip" than expected.
A warning is emitted to the audit log if some of the patches that
were expected to rollback couldn't be because of some other change
in the patch application history.
There situations will only exist if the EAP server is patched through
other means than RHQ after it has been patched using RHQ thus creating
and inconsistency between what RHQ sees as the deployment history of
the destination and the real state on the EAP resources.
The release branch commit hash is this:
Moving to ON_QA as available for test with build: