Bug 1018213

> 5. Once install completes, relocate the base directory /tmp/jon to /tmp/jon-new.

I can say it was never in the design or expectation that we support the usecase that once you install JON, that you can then move that JON installation to a new location.

It may not have been intentional but the fact that we supported the externalization of RHQ_SERVER_HOME and RHQ_AGENT_HOME as configurable environment variables and still provide these in the environment scripts would lead me to believe that perhaps this was the intended design.

In either case, this is what customers are doing today and is what JBoss supports.

Moving to ER05 as missed the cutoff for ER04.

flagging this as high risk.  if this is implemented, recommending a full round of installation testing ... all platforms ... windows, RHEL, Solaris ... as well as more testing around testcases as yet to be defined ... 

Possible testcases:
1) network drive letter changes on windows
2) mount point changes on Linux
3) moving storage node to a new directory and changing environmental variables
4) some puppet specific zip and unzip thing ?
5) requalification of windows, solaris, and RHEL
6) other??? 

when the GUI install was removed ... the install has been changing and changing and changing ... and there haven't been requirements or testcase development around "install".  

recommendation:  this would need to go thru the "virtuous QE cycle", as follows:

1) developer demo ... including a discussion and brainstorm of testcases.  gss to be present at this demo and provide input into the testcases
2) structured TCMS testcase development on what the testcases are here
3) TCMS testcase execution ... on windows, solaris, and RHEL

possible GA slip on this ...

For QE:

Primary testcase:

Install JBoss ON in /opt/jboss/jon
Rename /opt/jboss/jon to /opt/jboss/jboss-on
Restart JON, should fail.
Rename environmental variables, should work.

Do same/similar on Windows.

adding DOCUMENTATION keyword, and doc person ... to review JON documentation in this area.

This is why standalone-full.xml has absolute paths for the key/truststores:

        // https://issues.jboss.org/browse/WFLY-1177 - we need to resolve the paths right now. the user won't be able
        // to change these again in the future unless they go directly into standalone.xml and change it manually
        String truststoreFileString = connector.getSslConfiguration().getCaCertificateFile();
        truststoreFileString = resolveExpression(mcc, truststoreFileString);
        connector.getSslConfiguration().setCaCertificateFile(truststoreFileString);

        String keystoreFileString = connector.getSslConfiguration().getCertificateKeyFile();
        keystoreFileString = resolveExpression(mcc, keystoreFileString);
        connector.getSslConfiguration().setCertificateKeyFile(keystoreFileString);

I'll have to investigate if that bug was fixed in our version of EAP. If so, we can avoid putting in hardcoded absolute paths. If that bug still exists, we'll have to figure out what we can do here (perhaps use relative paths as opposed to ${} notation).

If it isn't fixed then relative paths -- if they work out to where we expect these files to exist by default -- will be fine.

Otherwise we will need to figure out how to replace these during startup as we do not support user modifications to standalone-full.xml at this time.

git commit to master:

0ed021e037a00ab1c0c89664093f5d9ca6626dad
0738e579f8f40e7d703fd5e98a54d35d75a04520

git commit to release/jon3.2.x:

adebf5ff232dbf418418753716a9aaec99797782
7da9fa1358efec9d0bdd26962ca60f3d479d3b2e

All the files mentioned above have been fixed to allow relative paths or the paths are automatically updated by the container. The commits above noted in comment #16 and the commits mentioned in this comment resolve the reported issue.


Additional release/jon3.2.x commits:

https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=770f2cdb935066501bd57db72466fb5226a0cc71

https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=23df184ff3b7c8d988985c13f8c887906f65507f

https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=6e09ef87a476b15c7853a7f7837374ddab7344b7

Additional release/jon3.2.x commit:

https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?h=release/jon3.2.x&id=76437304bb569767cfe2fcb19eb9fc9ea2942d54

Moving to ON_QA as available for testing with new brew build.

Mass moving all of these from ER6 to target milestone ER07 since the ER6 build was bad and QE was halted for the same reason.

verified in windows with er7
steps taken:
1. install jon server, sorage and agent in "jon3" direcotry
2. start services -> started, GUI accessible
3. stop services (rhqctl stop)
4. remove windows services (they have hard-coded paths to executables ) (rhqctl remove)
5. set RHQ_SERVER/STORAGE/AGENT_HOME env. vars
6. move jon from "jon3" to "jon4"
7. re-install services (rhqctl install)
8. re-start services (rhqctl start) -> all 3 services re-started correct, data from previous start visible 

screen-shots and steps in console attached

Created attachment 832134 [details]
windows_jonpath.log

Created attachment 832135 [details]
windows_service-jon3

Created attachment 832136 [details]
windows_service-jon4

verified on rhel6 with er7
steps taken:
1. install jon server, storage and agent in "jon" directory
2. rename "jon" to "jon2"
3. change RHQ_SERVER/STORAGE/AGENT_HOME properties
4. start server, storage and agent -> started without issues, no hard-coded full path

Created attachment 832149 [details]
linux_jonpath.log