Bug 1033321 - storage config relative path breaks upgrade
storage config relative path breaks upgrade
Status: NEW
Product: RHQ Project
Classification: Other
Component: Installer, Storage Node (Show other bugs)
4.9
Unspecified Unspecified
urgent Severity urgent (vote)
: GA
: RHQ 4.13
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On: 1074636 1074637
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-21 15:56 EST by John Mazzitelli
Modified: 2014-07-07 15:43 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Mazzitelli 2013-11-21 15:56:01 EST
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.
Comment 1 John Mazzitelli 2013-11-21 16:03:27 EST
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.
Comment 2 John Mazzitelli 2013-11-21 16:07:20 EST
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.
Comment 3 Jay Shaughnessy 2013-11-21 16:14:47 EST
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.
Comment 4 Larry O'Leary 2013-11-21 16:19:48 EST
(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.
Comment 5 John Mazzitelli 2013-11-21 17:12:48 EST
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.
Comment 6 John Mazzitelli 2013-11-21 17:17:48 EST
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.
Comment 7 Mike Foley 2013-11-22 07:52:44 EST
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.
Comment 9 Heiko W. Rupp 2014-03-09 15:31:46 EDT
Is this an issue for users to upgrade from 4.9 to 4.10? Or then afterwards to 4.11?
Comment 10 John Sanda 2014-03-10 11:00:22 EDT
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.
Comment 11 Heiko W. Rupp 2014-05-08 10:42:54 EDT
Bump the target version now that 4.11 is out.
Comment 12 Jay Shaughnessy 2014-07-07 15:43:29 EDT
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.

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