Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for configurable JDKs #316

Merged
merged 5 commits into from
Jan 8, 2021
Merged

Conversation

sfcoy
Copy link
Contributor

@sfcoy sfcoy commented Oct 21, 2020

This PR makes the following changes:

  • Adds support for user configurable JDKs in order to enable JDK 11 or newer to be installed

I tested this PR by...

  1. Creating and running Java 8 based clusters
  2. Creating and running Java 11 based clusters

Copy link
Owner

@nchammas nchammas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good to me! Left some minor comments about the details.

One other thought that comes to me is that it would be useful to add Java 8 vs. 11 to the acceptance tests somehow. Not that every test should run twice, once with Java 8 and once with Java 11, but that there should be at least one test that somehow makes sure this Java flag is working for some common use case.

Do you think there is a simple way we can add a test like that?

flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/flintrock.py Outdated Show resolved Hide resolved
sfcoy added 2 commits October 30, 2020 15:38
…dk_repo function

Change jdk option name to java-version/java_version and make it an int
If the correct version of Java is already installed then do not install again
Add warning if the java version is being downgraded
@sfcoy sfcoy force-pushed the multi-jdk-support branch from 5d53804 to 45e1523 Compare October 30, 2020 07:25
 * add spot request duration (looks like this was not working before?)
 * add java version
@sfcoy sfcoy force-pushed the multi-jdk-support branch from 5c455a9 to 22623d4 Compare November 2, 2020 07:11
Copy link
Owner

@nchammas nchammas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sfcoy, this looks great! I think a couple final tweaks and it's ready to go. I will also make time to test it myself this week.

By the way, a request: If you can, please avoid force pushing the branch. It disconnects review comments from the PR commit history and makes it a bit harder to follow review comments over time.

I'm guessing you did it to overcome some troubles updating the branch from the latest master? At this point it may be easier to just manually delete the spot request duration stuff and push a new commit. I will squash the whole PR into a single commit when merging to master, anyway.

flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/flintrock.py Show resolved Hide resolved
Copy link
Contributor Author

@sfcoy sfcoy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other thought that comes to me is that it would be useful to add Java 8 vs. 11 to the acceptance tests somehow. Not that every test should run twice, once with Java 8 and once with Java 11, but that there should be at least one test that somehow makes sure this Java flag is working for some common use case.

Do you think there is a simple way we can add a test like that?

It would be nice if we could. However I am not currently up with modern python testing methodology (I'm a Java guy).
Right now I manually test four scenarios:

  1. Vanilla AMI with no Java installed
  2. Java 11 AMI with java-version: 8
  3. Java 11 AMI with java-version: 11
  4. Java 11 AMI with java-version: 14

I had to build my own Java 11 AMI because the only existing ones seem to require subscriptions and AWS was being cranky about these today (returning 400 errors).

flintrock/flintrock.py Outdated Show resolved Hide resolved
@@ -722,6 +726,8 @@ def stop(cli_context, cluster_name, ec2_region, ec2_vpc_id, assume_yes):
help="Path to SSH .pem file for accessing nodes.")
@click.option('--ec2-user')
@click.option('--ec2-spot-price', type=float)
@click.option('--ec2-spot-request-duration', default='7d',
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @nchammas ,
I suspect that "add-slaves" in master is not working right now because this "ec2_spot_request_duration" parameter is missing.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I'll report this over on #315.

flintrock/core.py Outdated Show resolved Hide resolved
flintrock/core.py Outdated Show resolved Hide resolved
flintrock/flintrock.py Show resolved Hide resolved
@nchammas
Copy link
Owner

Just noting for the record that this issue potentially closes #313.

@sfcoy - Sorry about the delay in reviewing the latest changes here. I intend to get to them this upcoming week and get this merged in!

Copy link
Owner

@nchammas nchammas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is good to go. If I can trouble you for one more improvement, it would be to display a warning if the user launches a cluster with Hadoop < 3.3 and Java 11. Only Hadoop 3.3+ are compatible with Java 11+.

If you try to launch a cluster with Hadoop 3.2 and Java 11, you get an error like this on starting up HDFS:

2021-01-04 00:17:27,413 ERROR [main] namenode.NameNode (NameNode.java:main(1764)) -
 Failed to start namenode.
java.lang.ExceptionInInitializerError
        at org.eclipse.jetty.webapp.WebInfConfiguration.findAndFilterContainerPaths
(WebInfConfiguration.java:185)
...
Caused by: java.lang.IllegalArgumentException: Invalid Java version 11.0.9.1

I would probably add the check somewhere here:

if install_hdfs:
validate_download_source(hdfs_download_source)
hdfs = HDFS(
version=hdfs_version,
download_source=hdfs_download_source,
)
services += [hdfs]

No worries if you can't get to it. In that case, I will push an appropriate fix to this branch before merging it in, if you don't mind.

flintrock/core.py Outdated Show resolved Hide resolved
@@ -722,6 +726,8 @@ def stop(cli_context, cluster_name, ec2_region, ec2_vpc_id, assume_yes):
help="Path to SSH .pem file for accessing nodes.")
@click.option('--ec2-user')
@click.option('--ec2-spot-price', type=float)
@click.option('--ec2-spot-request-duration', default='7d',
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch. I'll report this over on #315.

@sfcoy
Copy link
Contributor Author

sfcoy commented Jan 5, 2021

This PR is good to go. If I can trouble you for one more improvement, it would be to display a warning if the user launches a cluster with Hadoop < 3.3 and Java 11. Only Hadoop 3.3+ are compatible with Java 11+.

If you try to launch a cluster with Hadoop 3.2 and Java 11, you get an error like this on starting up HDFS:

2021-01-04 00:17:27,413 ERROR [main] namenode.NameNode (NameNode.java:main(1764)) -
 Failed to start namenode.
java.lang.ExceptionInInitializerError
        at org.eclipse.jetty.webapp.WebInfConfiguration.findAndFilterContainerPaths
(WebInfConfiguration.java:185)
...
Caused by: java.lang.IllegalArgumentException: Invalid Java version 11.0.9.1

I would probably add the check somewhere here:

if install_hdfs:
validate_download_source(hdfs_download_source)
hdfs = HDFS(
version=hdfs_version,
download_source=hdfs_download_source,
)
services += [hdfs]

No worries if you can't get to it. In that case, I will push an appropriate fix to this branch before merging it in, if you don't mind.

The Hadoop team must have added a Java version check, because I have actually built and run this combination before.

@nchammas
Copy link
Owner

nchammas commented Jan 8, 2021

I've filed #322 to track adding some sort of compatibility check to Flintrock.

Merging this in. Thank you for persisting through the review process @sfcoy and getting this important enhancement in!

@nchammas nchammas merged commit 6792626 into nchammas:master Jan 8, 2021
@sfcoy
Copy link
Contributor Author

sfcoy commented Jan 10, 2021

I've filed #322 to track adding some sort of compatibility check to Flintrock.

Merging this in. Thank you for persisting through the review process @sfcoy and getting this important enhancement in!

No worries mate. I was actually becoming a little concerned about you, given the Covid situation and all.

maxpoulain pushed a commit to adotmob/flintrock that referenced this pull request Jan 19, 2021
* Add support for configurable JDKs

* Perform complete adoptopenjdk.repo installation in install_adoptopenjdk_repo function
Change jdk option name to java-version/java_version and make it an int
If the correct version of Java is already installed then do not install again
Add warning if the java version is being downgraded

* Fix add_slaves functionality
 * add spot request duration (looks like this was not working before?)
 * add java version

* Cleaned up and clarified the Java installation logic.
Added more documentation

* tweak wording of docstring

Co-authored-by: Nicholas Chammas <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants