Bug 1376460

Summary:	[GSS](6.4.z) JBoss CLI patch command doesn't honor custom configuration location
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Abhijit humbe <abhumbe>
Component:	Patching	Assignee:	Peter Palaga <ppalaga>
Status:	CLOSED NOTABUG	QA Contact:	Jan Martiska <jmartisk>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.4.10	CC:	abhumbe, bmaxwell, brian.stansberry, jason.greene, jawilson, jdoyle, kconner, msimka, olubyans, ppalaga
Target Milestone:	---	Flags:	abhumbe: needinfo-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-18 19:11:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Abhijit humbe 2016-09-15 13:20:36 UTC

Description of problem:
Suppose we are using custom standalone directory(example: standalone_dev) while starting EAP 6.4.0+ instance, and if we try to rollback applied CP patch, with "--rest-configuration=true" option, it always restore configuration files from default location(JBOSS_HOME/standalone) not from the "standalone_dev" directory. I can see same result when I try to rollback patch when JBoss instance is up through management console and through JBoss CLI in connected mode.

Comment 1 Alexey Loubyansky 2016-09-22 13:22:19 UTC

First of all, we do not support configuration patching at the moment. Which means when user applies a patch, the configuration will not change (wherever it is located). We do support optionally resetting the configuration during rollback though. So it affects only rolling back user-made changes to the configuration.

Nevertheless, that is an interesting one.

The problem with custom configuration locations is that only the user knows where they are located, the patching mechanism is not aware of them. Of course, if the user sets the system property to point to the custom config, the patching mechanism can back it up and then reset it when rolling back a patch.
We could support this case.

On the other hand, if a user has a custom config location, chances are, there are multiple custom config locations. (In fact, this is actually the case for the customer.) And only the user knows where they are. We can back up the active one (the one the user is using at the time patching is performed) but the rest of the custom config locations will be left behind, although the binary changes will take place for every one of them.
Does the customer expect all of its custom config locations to be reset during rollback?

There could also be case when a patch is applied using one custom configuration and rolled back using another custom configuration location.
Also custom configuration locations can be created after a patch is applied. I am not sure how the patching mechanism should behave in these case, at the moment. While I do accept that when the active custom configuration is not backed up during patching and not reset during rollback, it's weird, I am not sure we should support custom configuration locations. As backing up the active custom config location will not allow us to say that the patching mechanism now supports custom configuration locations.