The usage of relative paths in cassandra.yaml is breaking an upgrade if the new upgraded server is installed in a different location than the original installation. Replication (I'm using a master build of 4.10-SNAPSHOT): 1. Unzip new server distro under /opt/rhq 2. Install it : rhqctl install --start 3. Verify its all running and things are OK. 4. Shutdown : rhqctl stop 5. Now unzip the server distro in a completely different location - NOT under /opt/rhq. For example, install it under /home/username/myrhq 6. Now upgrade the old install : rhqctl upgrade --from-server-dir /opt/rhq/rhq-server-4.10 At this point, you will notice you have and rhq-data directory here: /home/username/myrhq/rhq-data and all the storage node data is under there. But it should have reused the data in /opt/rhq/rhq-data. The problem is cassandra.yaml has relative paths like "../../../rhq-data/" and that is relative to the original install dir of /opt/rhq. Now that we have the new install in a different parent location of /home/username/myrhq that relative path is broken and not pointing to the original data location.
One possible solution is that during the rhqctl upgrade, the storage installer should look at the --from-server-dir value (which is required for all rhqctl upgrade executions) and if that location has a rhq-data directory, the storage installer should then set inside cassandra.yaml (and whereever else is needed) the ABOSLUTE path to that location of the rhq-data location.
Larry - another side effect of the "get rid of absolute paths from config files" You'll need to look at this proposed solution in Comment #1 and tell us if this is a problem. The issue is we shouldn't (and probably in some cases can't) copy the original rhq-data content - we need to maintain the original storage data where it originally was. But if we decide to install the new upgraded server in a different location, relative paths break.
I think upgrades (from versions that had storage) should determine the location of the storage data dir from information under --from-server-dir and then apply that absolute path to the new storage node config. The only time a relative path make sense, afaics, is at original install time or when upgrading from a non-storage version, and when the user has not already set a directory in the rhq-storage.properties.
(In reply to John Mazzitelli from comment #2) > The issue is we shouldn't (and probably in some cases can't) copy the > original rhq-data content - we need to maintain the original storage data > where it originally was. But if we decide to install the new upgraded server > in a different location, relative paths break. Why not? If I use defaults then wouldn't I expect everything to be self-contained in the upgraded location? Assuming RHQ_HOME is the same for my upgraded server location, the default rhq-data directory would be unchanged. If I put RHQ_HOME in a completely new location, then I would expect that the upgrade would take care of not only moving my existing configuration to the new location but the existing data. So, why shouldn't we move it? In the event that I put it on a separate user-defined partition, I am now getting into the realm of the user needing to explicitly define this path anyway using the appropriate rhq-data-dir command-line argument or property. (In reply to John Mazzitelli from comment #1) > One possible solution is that during the rhqctl upgrade, the storage > installer should look at the --from-server-dir value (which is required for > all rhqctl upgrade executions) and if that location has a rhq-data > directory, the storage installer should then set inside cassandra.yaml (and > whereever else is needed) the ABOSLUTE path to that location of the rhq-data > location. If we are considering doing this then I think the better solution is to maintain the data directory location in the rhq-server or rhqctl properties files and dynamically create yaml on each startup of the storage node. In this respect the storage node would actually need to be started/bootstrapped by an rhq process that was part of rhqctl.
in my case, I installed across file systems (I installed the original on /opt and the upgrade was on /home and they are different file systems, so a true mv is not possible). In that case, it would require potentially copying large amounts of data (potentially gigabytes?? How big does the C* data get?) I was hoping we could eliminate that.
One other point to bring up, if someone preconfigured storage properties to point to their own data location (non-default), then we need to be sure to honor that and not move the data anywhere.
This will affect upgrading from JON 3.2 to JON 3.2.1 ... so I am setting the priority high so the work gets prioritized.
Is this an issue for users to upgrade from 4.9 to 4.10? Or then afterwards to 4.11?
We added support for relative paths in bug 1018213 which was well after 4.9 went out. Upgrades from 4.9 to 4.10 should not be an issue. This should only be an issue when upgrading from 4.10; as such, I think we can bump this to 4.11.
Bump the target version now that 4.11 is out.
Pushing to 4.13. Workaround is to unzip the new version in a sibling directory (i.e. under the same parent as the version being upgraded from). This is our recommended strategy in general.