Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of Alex.Brett@citrix.com
 designates 185.25.65.24 as permitted sender)
From: Alex Brett <Alex.Brett@citrix.com>
To: David Nalley <david@gnsa.us>, "dev@cloudstack.apache.org"
	<dev@cloudstack.apache.org>
CC: Hugo Trippaers <htrippaers@schubergphilis.com>, Frank Zhang
	<Frank.Zhang@citrix.com>, Rajani Karuturi <rajani@apache.org>, "Rayees
 Namathponnan" <rayees.namathponnan@citrix.com>
Subject: RE: Review Request 25289:
 CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version
Thread-Topic: Review Request 25289:
 CLOUDSTACK-7474-Failed-to-start-MS-with-java7-version
Thread-Index: AQHPxz/zMRPjUFnCT0CV7SrwC2o6+ZvvA9uAgADtIICAAAExgIAAJlfR
Date: Thu, 4 Sep 2014 00:12:47 +0000
Message-ID: <D43103802360B147A3BAB085E3D078C14F3027@AMSPEX01CL01.citrite.net>
References: <20140903093213.16961.33225@reviews.apache.org>
 <20140903234055.16961.25713@reviews.apache.org>,<CAKprHVbtJXK6u8WG+aTnfSM08C6VR38aV7bVEVAkuYuTt5VRkA@mail.gmail.com>
In-Reply-To: 
 <CAKprHVbtJXK6u8WG+aTnfSM08C6VR38aV7bVEVAkuYuTt5VRkA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

On 04 September 2014 00:45, David Nalley [david@gnsa.us] wrote:
> On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett <alex.brett@citrix.com> wrote:
>> To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 a=
nd 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 defaul=
t, 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 fi=
ne (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, se=
tting it to be Java 7 (which we know should be installed by the RPM depende=
ncies) - 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) instea=
d of 6.3 - we do already say to install all hotfixes etc, which in theory m=
eans 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 update=
s. 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 ver=
sion 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 t=
he management server / agent won't start after upgrade, but is at least a r=
easonably easy fix.

Alex=