Bug 1136945 - EAP Patch Purge Failed When Mixed Patches Were Previously Deployed
Summary: EAP Patch Purge Failed When Mixed Patches Were Previously Deployed
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- Other
Version: JON 3.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ER04
: JON 3.3.0
Assignee: Lukas Krejci
QA Contact: Mike Foley
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: JON3-10, PRODMGT-544
TreeView+ depends on / blocked
 
Reported: 2014-09-03 16:11 UTC by Matt Mahoney
Modified: 2014-12-11 13:59 UTC (History)
1 user (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-12-11 13:59:38 UTC


Attachments (Terms of Use)
server.log (338.85 KB, text/plain)
2014-09-03 16:14 UTC, Matt Mahoney
no flags Details

Description Matt Mahoney 2014-09-03 16:11:13 UTC
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:

Comment 2 Matt Mahoney 2014-09-03 16:14:03 UTC
Created attachment 934144 [details]
server.log

Comment 3 Lukas Krejci 2014-09-09 08:33:30 UTC
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.

Comment 5 Lukas Krejci 2014-09-22 17:03:34 UTC
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.

Comment 6 Lukas Krejci 2014-09-22 20:46:58 UTC
The release branch commit hash is this:
7a45c9632d23d4b8ef3cdec49b94e3dcf09bce67

Comment 7 Simeon Pinder 2014-10-01 21:33:07 UTC
Moving to ON_QA as available for test with build:
https://brewweb.devel.redhat.com/buildinfo?buildID=388959


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