cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Brett <>
Subject RE: Review Request 25289: CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version
Date Thu, 04 Sep 2014 00:12:47 GMT
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.

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
* 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
* 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.
* 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.

View raw message