Packaging tests use Java 8

[nik9000]

To do this we:

1. All the rpm based distros we test support Java 8. We just ask to install
   it.
2. There is a ppa that works for the Ubuntus. We just add that for them.
3. Debian Jessie has Java 8 in its backports. We just add that repository.
4. Debian Wheezy doesn't have Java 8 easily accessible so we drop it. We
   could add it back with Orache Java 8 at a later date but that will take a
   few more backflips and won't support things like vagrant-cachier.

This required a ton of rebuilding of vagrant boxes so it also fixes:

1. apt-get update is run too frequently
2. Lots of weird warning messages are spit out of apt-get
3. Switch from the chef provided based images to those provided by boxcutter.
   The chef images has left vagrant atlas!

Closes #13366

[nik9000]

Because this contains a few cleanup operations I'll likely backport this to 2.x and 2.0 without the Java 8 portions once this is merge to master.

[spinscale]

Am I doing it wrong? Running mvn clean verify -Dtests.vagrant I get a fair share of these failures in the vagrant tests

[exec] trusty: # Exception in thread "main" java.lang.UnsupportedClassVersionError: org/elasticsearch/plugins/PluginManagerCliParser : Unsupported major.minor version 52.0

Is the default java on those VMs somewhat old? Should I delete my VMs? Anything potentially cached?

[tlrx]

Debian 7 is an officially supported OS for elasticsearch (see https://www.elastic.co/subscriptions/matrix) so I think we should really keep it

[spinscale]

I think it makes sense to add it back once there is proper java 8 support for it by a backporting repo and this release is released and not just master for development... If we dont have java 8 on the VM, we should ignore for now, thus +1000 for the comment

[nik9000]

I'm ok with dropping it because Wheezy is no longer Debian stable. And this is master which won't be released for a while.

I was playing around with it - I can get Oracle Java 8 on there if I spend some more time on it but I'd love to get this in so the master tests are sane again. We can add an issue for wheezy if we really want it back.

[tlrx]

I hit the same error as @spinscale even if I destroy the VMs first.

[nik9000]

Is the default java on those VMs somewhat old? Should I delete my VMs? Anything potentially cached?

Weird. I certainly wasn't seeing that error but I've been destroying and rebuilding those VMs a ton of times. So you probably have to destroy the VMs first, honestly.

[nik9000]

I hit the same error as @spinscale even if I destroy the VMs first.

Oh! Now I don't know.

[spinscale]

running vagrant destroy in the 'root' directory and rerunning the tests solved this for me, everything passing now, LGTM

[nik9000]

running vagrant destroy in the 'root' directory and rerunning the tests solved this for me, everything passing now, LGTM

Hurray! I'm playing with it again and coming to the same conclusion. You should be able to run vagrant destroy from any directory you want inside of elasticsearch.

[nik9000]

Destroying works for me.

@tlrx, does destroying it work for you?

If it does we can either:

1. Live with that or
2. File an issue about making sure we select the right java version and allow both to be installed.

[nik9000]

@tlrx, does destroying it work for you?

Just to keep things moving I'll merge this on Monday morning if I haven't heard from you. Its an improvement if the vagrant tests work in master for anyone because right now they work for no one.

[tlrx]

Unfortunately it still does not work for me:

$ uname -a
Linux portable 3.19.0-28-generic #30~14.04.1-Ubuntu
$ vagrant version
Installed Version: 1.7.4

I destroyed the VMS using vagrant destroy then set up the boxes using vagrant up --provision $box --provider virtualbox and run mvn clean install -DskipTests && mvn -Dtests.vagrant -pl qa/vagrant verify. Same thing if a remove all boxes with rm -rf ~/.vagrant.d.

It looks like the VMs are still using java 7.

If it's just on my computer I think you can merge, but that would be nice to check that it works on more than 2 (yours & @spinscale's) computers.

[tlrx]

I manually remove the .vagrant/ directory in the root directory and execute the tests again: it works.

LGTM then

[nik9000]

That is rough ! Thanks for tricking that down!
On Sep 14, 2015 6:18 AM, "Tanguy Leroux" notifications@github.com wrote:

I manually remove the .vagrant/ directory in the root directory and
execute the tests again: it works.

LGTM then

—
Reply to this email directly or view it on GitHub
#13422 (comment)
.

[nik9000]

Ok - now that I think about this - I can just backport this 100% for 2.0 and 2.x. It won't hurt anything to use Java 8 everywhere and, eventually, we can be a bit more picky. Maybe when working on #13392. Any objections to me just backporting this cleanly and getting those branches onto Java 8 for now?

[tlrx]

@nik9000 I don't have any objections

[nik9000]

Will do then.

[nik9000]

Backported to 2.x. Starting on 2.0.

[nik9000]

Backported to 2.0. Found #13557 in the process. Fun.