Branch: refs/heads/master Home: https://github.com/rhq-project/rhq Commit: 1b45c2af77fe3a4670bc4317508780f80ae3f0bc https://github.com/rhq-project/rhq/commit/1b45c2af77fe3a4670bc4317508780f... Author: Jay Shaughnessy <jshaughn(a)redhat.com&gt; Date: 2014-10-29 (Wed, 29 Oct 2014) Changed paths: M modules/common/cassandra-installer/src/main/java/org/rhq/storage/installer/StorageInstaller.java M modules/enterprise/server/installer/src/main/java/org/rhq/enterprise/server/installer/Installer.java M modules/enterprise/server/installer/src/main/java/org/rhq/enterprise/server/installer/InstallerService.java M modules/enterprise/server/installer/src/main/java/org/rhq/enterprise/server/installer/InstallerServiceImpl.java M modules/enterprise/server/server-control/src/main/java/org/rhq/server/control/command/AbstractInstall.java M modules/enterprise/server/server-control/src/main/java/org/rhq/server/control/command/Upgrade.java Log Message: ----------- [1139735, 1157480] More upgrade use cases that didn't work. [1139735] An upgrade with a number of storage nodes > than our replication factor (>= 4) could fail because our check for the storage cluster version can fail if the auth info or version info are not replicated to the currently running SNs. To avoid this, for ugrades we now push all storage cluster interaction to the post-upgrade step (i.e. rhqctl --storage-schema). This includes the schema creation for a new, remote storage cluster. [1157480] An upgrade of standalone storage node can fail because those installs may not have set proper DB props in rhq-server.properties. It wasn't required in the past but it is now. In the code we now make sure the properties are copied forward on upgrade. But there is also doco needed here because prior to upgrade from an earlier version, using standalone SNs, the old rhq-server.properties files will need to be updated. Also, update the --list-versions report to better reflect that it may need all SNs to be running to perform the storage schema version check.