Skip to content

Integration Test Revisions

Jump to bottom
Paul Rogers edited this page Mar 13, 2022 · 4 revisions

Revisions

  • The base image could contain all the required dependencies.
  • Single setup script rather than the current hodge-podge
  • Move all entry point functionality into a script
  • Use the build created in distribution.
  • Use standard Docker ways to manage processes.

Proposed Plan of Attack

Analysis:

  • Work out the Docker file used to create the Docker images.
  • What does that Docker file need? Where does it get the Druid artifacts? What other artifacts does it need? (Done)
  • What is the runtime setup? What is expected to occur in the shared directory?
  • How many container images does the build create? How do they differ?
  • How do the integration tests launch the desired Docker containers?
  • How do the integration tests interact with the Docker containers?
  • How do we build the public Docker file and its scripts used by the tutorial?

From this, we can work out an alternative design:

  • Modify the pom.xml files and projects to produce the needed artifacts in the correct way.
  • Produce Docker images as Maven artifacts (though, unfortunately, they can't live in the Maven build tree.)
  • Work our the proper way to launch the images and run the integration tests.

The alternative design:

  • Build the context manually. Keep notes, or create an ad-hoc script.
  • Test the original Docker file.
  • Validate the container manually.
  • Create a script to validate the container.
  • Launch the container to at least ensure the service starts.
  • Modify the Dockerfile and the associated scripts.
  • Re-validate the container build.
  • Create a new druid-docker project.
  • Create the Docker context in that project's target directory in the test-compile phase.
  • Create the Docker container in the package phase.
  • Run tests from the integration-test module.

Revised design:

  • Create a new branch, cherry-pick changes from extn branch (Done)
  • Create a docker directory for docker-related items. (Done)
  • Create a base-docker project (Done)
  • Create a trivial container following this outline (Done)
  • Add additional content step-by-step (Done)
    • ZK
    • Python
    • MySQL
    • Scripts
    • Keys
    • Other odd bits
    • Entry point
  • Create the shared folder contents
    • Put in base-docker/target/shared
    • Copy files in the compile phase
  • Create a the test-docker project. (Done)
    • Expand Druid tarball into directories

The Docker work was the easy part. The hard part are the test. They are too complex to tackle all at once. Instead:

  • Pick one group, say the high-availability group.
  • Create a new Maven project.
  • Migrate the tests for that group to the new project. Ensure the code builds.
  • Launch cluster by hand
    • Simple one-service script
    • Repeat for each service
    • Launch script with env vars
    • Test-specific cluster script works
  • Detangle the launch scripts. Create a new one (or ones).
  • Move the Docker Compose scripts.
  • Copy base shared folder to a temp location
  • Launch containers
  • Run tests

Stages:

  • Basic functionality
    • Keep the shared directory in home
    • Keep docker compose files as-is
  • Build the shared directory in target somewhere
  • Push group-specific stuff into the container script, out of docker-compose
  • Different solution for configs

Migration path:

  • Create the above in parallel with the existing material
  • Migrate integration tests
  • Create the test which is the goal of this whole mess.
    • Port the test code
  • Later migrate the docker build
  • What to do with the K8s integration test stuff?

References:

Design Details

test-docker

Placed in the build sequence after distribution, before integration-tests.

docker-tests

Root project for ITs. Migrated from integration-tests. Holds common files.

Integration Test Projects

  • Sources for a group
  • Resources used by the tests
  • Docker-compose file

Integration Test Usage

Project contains a start-cluster.sh script to bring up the Docker cluster manually, and a stop-cluster.sh to bring it down.

To run tests manually:

  • Build the project up through distribution
  • Build base image (only when things change)
  • Build Druid image (when build changes)
  • start-cluster.sh
  • In the debugger, run a test
  • stop-cluster.sh

Operational Notes

List images:

docker images

Launch a disposable container with a shell:

docker run --rm -it --entrypoint sh org.apache.druid/test-docker:0.23.0-SNAPSHOT

Notes & TODO

  • Why does docker-compose.base.yml mount src/test/resources as a volume?
    • Create a temporary hack. Remove it: docker-tests/src/test/resources
  • Rename env files to end with .env
  • Rename .yml files to .yaml
  • Can there be just one supervisor conf file? With contents for target service?
  • Rename Docker compose files to just docker-compose.yaml.
  • Rename base-docker to base-test-image
  • Rename test-docker to test-image
  • Move start-mysql.sh to /usr/local
  • Put Druid libs in /usr/local/druid-libs to make merging easier
Clone this wiki locally