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): JON 3.3 How reproducible: 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) 3. Actual results: Purge failed. Expected results: Purge should not fail. Additional info:
Created attachment 934144 [details] server.log
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: master: d9beded5301ae12e2e20a00dc26c6e0e7cf80962 release/jon3.3.x: 14c1e368f6e025e8013646cc863897afb10be99b [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 non-sensical)). 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 or applications). 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: 7a45c9632d23d4b8ef3cdec49b94e3dcf09bce67
Moving to ON_QA as available for test with build: https://brewweb.devel.redhat.com/buildinfo?buildID=388959