On Wed, Sep 3, 2014 at 8:12 PM, Alex Brett <alex.br...@citrix.com> wrote: > On 04 September 2014 00:45, David Nalley [da...@gnsa.us] wrote: >> On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett <alex.br...@citrix.com> 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
