spark-instrumented-optimizer/resource-managers/kubernetes/integration-tests
Stavros Kontopoulos 7d44bc2640 [SPARK-25835][K8S] Create kubernetes-tests profile and use the detected SCALA_VERSION
## What changes were proposed in this pull request?

- Fixes the scala version propagation issue.
- Disables the tests under the k8s profile, now we will run them manually. Adds a test specific profile otherwise tests will not run if we just remove the module from the kubernetes profile (quickest solution I can think of).
## How was this patch tested?
Manually by running the tests with different versions of scala.

Closes #22838 from skonto/propagate-scala2.12.

Authored-by: Stavros Kontopoulos <stavros.kontopoulos@lightbend.com>
Signed-off-by: Sean Owen <sean.owen@databricks.com>
2018-10-26 08:49:27 -05:00
..
dev [SPARK-25835][K8S] Create kubernetes-tests profile and use the detected SCALA_VERSION 2018-10-26 08:49:27 -05:00
scripts [SPARK-23010][K8S] Initial checkin of k8s integration tests. 2018-06-08 15:15:24 -07:00
src/test [SPARK-25291][K8S] Fixing Flakiness of Executor Pod tests 2018-09-18 11:43:35 -07:00
tests [SPARK-25021][K8S] Add spark.executor.pyspark.memory limit for K8S 2018-09-08 22:18:06 -07:00
pom.xml [SPARK-25592] Setting version to 3.0.0-SNAPSHOT 2018-10-02 08:48:24 -07:00
README.md [SPARK-23010][K8S] Initial checkin of k8s integration tests. 2018-06-08 15:15:24 -07:00

layout title
global Spark on Kubernetes Integration Tests

Running the Kubernetes Integration Tests

Note that the integration test framework is currently being heavily revised and is subject to change. Note that currently the integration tests only run with Java 8.

The simplest way to run the integration tests is to install and run Minikube, then run the following:

dev/dev-run-integration-tests.sh

The minimum tested version of Minikube is 0.23.0. The kube-dns addon must be enabled. Minikube should run with a minimum of 3 CPUs and 4G of memory:

minikube start --cpus 3 --memory 4096

You can download Minikube here.

Integration test customization

Configuration of the integration test runtime is done through passing different arguments to the test script. The main useful options are outlined below.

Re-using Docker Images

By default, the test framework will build new Docker images on every test execution. A unique image tag is generated, and it is written to file at target/imageTag.txt. To reuse the images built in a previous run, or to use a Docker image tag that you have built by other means already, pass the tag to the test script:

dev/dev-run-integration-tests.sh --image-tag <tag>

where if you still want to use images that were built before by the test framework:

dev/dev-run-integration-tests.sh --image-tag $(cat target/imageTag.txt)

Spark Distribution Under Test

The Spark code to test is handed to the integration test system via a tarball. Here is the option that is used to specify the tarball:

  • --spark-tgz <path-to-tgz> - set <path-to-tgz> to point to a tarball containing the Spark distribution to test.

TODO: Don't require the packaging of the built Spark artifacts into this tarball, just read them out of the current tree.

Customizing the Namespace and Service Account

  • --namespace <namespace> - set <namespace> to the namespace in which the tests should be run.
  • --service-account <service account name> - set <service account name> to the name of the Kubernetes service account to use in the namespace specified by the --namespace. The service account is expected to have permissions to get, list, watch, and create pods. For clusters with RBAC turned on, it's important that the right permissions are granted to the service account in the namespace through an appropriate role and role binding. A reference RBAC configuration is provided in dev/spark-rbac.yaml.