cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <>
Subject Re: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version
Date Thu, 04 Sep 2014 00:49:21 GMT
On Wed, Sep 3, 2014 at 8:12 PM, Alex Brett <> wrote:
> On 04 September 2014 00:45, David Nalley [] wrote:
>> On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett <> wrote:
>>> To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and Java
7 installed, the default behaviour with the alternatives mechanism makes 1.6 the default Java
instance (you can manually set 1.7 as the default, but this is an extra step). This means
that the management server / KVM agent then fail to work.
>>> In 6.5 if you have both then by default Java 7 is used, and all works fine (not
sure about 6.4 or 7, I've not tested them).
>> Perhaps we add a Conflicts with java 1.6 - it would be somewhat ugly,
>> and if you run into it  you would need to know to yum remove, but that
>> would keep you from having an installation at all rather than
>> expecting it to work and trying to debug.
> I'd have thought this would prove problematic over upgrade - as you'd have a conflict
that the new version would need to have 1.6 removed, but you can't do that without removing
your old version first. There's also the issue of if the user wants to have both around for
other tools they're running on the same machine.

Both valid points.

> Some solutions that don't break upgrade that I can see are:
> * Rayees change in the review to point directly at Java 7, with the caveat that this
might have some cross platform issues

Yes, but cross-platform issues - there are people running on platforms
besides what we package for; and with JDKs other than what we assume
in our package scripts. Hardcoding is bad all the way around.

> * Somehow automating the alternatives mechanism, i.e. doing a check as part of management
server startup somewhere that if the default Java is 1.6, setting it to be Java 7 (which we
know should be installed by the RPM dependencies) - a little ugly as we are changing a user's
default underneath them, and may also have cross platform issues

Ugh, please no, changing underlying platform without very clearly
communicating it is bad. We'll invoke the ire of every BOFH using
CloudStack :)

> * Require use of 6.5 (or possibly 6.4 if the version that has works) instead of 6.3 -
we do already say to install all hotfixes etc, which in theory means people should be there
(yum update / upgrade on a 6.3 system will make it 6.5+), though I think we know in practise
a lot of users aren't as they prefer to keep things at a stable state or only apply very specific
updates. I guess this would be done by specifying a minimum Java version required that is
only in the appropriate release or later.

This is easy in CentOS; but more painful in RHEL. We could easily
Require: centos-release-6.5 or redhat-release (with an if statement if
centos-release doesn't provide redhat-release, but I think it does)

> * Don't actually block it in the RPM, but check in the init script what version of Java
we're going to end up picking up, and if it's 1.6 fail with a clear error message suggesting
the user changes the default - still means the management server / agent won't start after
upgrade, but is at least a reasonably easy fix.

This is probably most reasonable of all of the solutions IMO.

> Alex

View raw message