Requirements

Requirements for 6.3

• Ability to apply a patch to single hosts
• Ability to apply a patch to a standalone server
• Ability to roll-back a patch on a single host
• Ability to roll-back a patch on a standalone server

Requirements for beyond 6.3

• Ability to patch server-groups
• Ability to patch whole topology

Reference Materials

• EAP documentation on patching - https://access.redhat.com/site/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html-single/Installation_Gu…
• EAP 6.2 patching implementation details:Single Installation Patching , https://mojo.redhat.com/docs/DOC-180896
• EAP multipatch demo: https://mojo.redhat.com/docs/DOC-190727

User Workflows

Standalone Server

1. User obtains a patch file (one-off patch, minor product update, or cumulative patch).
   1. This can be from the customer support portal or another means.
2. The user goes to the admin console GUI of a standalone EAP instance.  The user can easily find the location in the user interface where they can apply a patch to this server.
   1. The user can check for conflicts before applying the patch.  The UI should inform the user what conflicts, if any were found and what the user can do to fix these conflicts.
   2. As the patch is applied, the user can clearly see the system restarting and taking the new version.  They should not be kicked out of the user interface in this process if possible.
3. The user can see the history of patches (or at least the last patch) applied to this server, and can roll back the last patch applied if needed.  Note that users cannot roll back minor versions - see patch type workflows below for more info.

Domain Server

1. User obtains a patch file (one-off patch, minor product update, or cumulative patch).
   1. This can be from the customer support portal or another means.
2. The user goes to the admin console GUI of a domain.  Using the host controller, the user can apply a patch (? need more information here)
   1. The user can check for conflicts before applying the patch.  The UI should inform the user what conflicts, if any were found and what the user can do to fix these conflicts.
   2. As the patch is applied, the user can clearly see the system restarting and taking the new version.  They should not be kicked out of the user interface in this process if possible.
3. The user can see the history of patches  (or at least the last patch) applied to this server, and can roll back the last patch applied if needed.  Note that users cannot roll back minor versions - see patch type workflows below for more info.

Patch Type workflows

https://mojo.redhat.com/docs/DOC-17072