Versions Compared

Old Version 2

changes.mady.by.user Aljoscha Krettek

Saved on

compared with

New Version Current

changes.mady.by.user Martijn Visser

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Currently, this is the old text from Creating a Flink Release. Slated to be updated soon.

Verifying a Release Candidate

Info

It is NOT necessary to run all checks to cast a vote for a release candidate.
However, you should clearly state which checks you did.
The release manager needs to ensure that each following check was done.

...

Checking Artifacts

Some of these are strictly required for a release to be ASF compliant.

  • Check if checksums and GPG files match the corresponding release files (required)
    A detailed description on how this is done can be found in the apache.org documentation about verifying releases.

  • Verify that the source archives do not contains contain any binaries (required)

  • Check if Build the source release is building properly with Maven (including license header check (default) and checkstyle). Also the tests should be executed (mvn clean verify)
  • check build for custom hadoop version
    • check build for Scala 2.11
    Verify that the LICENSE and NOTICE file is correct for the binary and source release.
  • All dependencies must be checked for their license and the license must be ASL 2.0 compatible (http://www.apache.org/legal/resolved.html#category-x)
  • The LICENSE and NOTICE files in the root directory refer to dependencies in the source release, i.e., files in the git repository (such as fonts, css, JavaScript, images)
    • The LICENSE and NOTICE files in flink-dist/src/main/flink-bin refer to the binary distribution and mention all of Flink's Maven dependencies as well
    Check that all POM files point to the same version (mostly relevant to examine quickstart artifact files)
  • Read the README.md file

 

Functional: (checks for delivering a release with good quality)

...


Checking Licenses

These checks are strictly required for a release to be ASF compliant.

Important: These checks must be performed for

  • the Source Release
  • the Binary Release
  • the Maven Artifacts (jar files uploaded to Maven Central)

Checks to be made include

  • All Java artifacts must contain an Apache License file and a NOTICE file. Python artifacts only require an Apache License file.
  • Non-Apache licenses of bundled dependencies must be forwarded
  • The NOTICE files aggregate all copyright notices and list all bundled dependencies (except Apache licensed dependencies) 

A detailed explanation on the steps above is in https://cwiki.apache.org/confluence/display/FLINK/Licensing (see the bottom of the document for the actions to take)


Testing Functionality

This is not necessarily required for a release to be ASF compliant, but required to ensure a high quality release.

This is not an exhaustive list - it is mainly a suggestion where to start testing.

Built-in tests

Check if the source release is building properly with Maven, including checkstyle and all tests (mvn clean verify)

  • Build for Scala 2.12

Run the scripted nightly tests: https://github.com/apache/flink/tree/master/flink-end-to-end-tests

Run the Jepsen Tests for Flink: https://github.com/apache/flink/tree/master/flink-jepsen

Quickstarts

Verify that the quickstarts for Scala and Java are working with the staging repository for both IntelliJ and Eclipse.

Simple Starter Experience and Use Cases

Run all examples from the IDE (Eclipse & IntelliJ)

Start a local cluster (start-cluster.sh) and verify that the processes come up

  • Examine the *.out files (should be empty) and the log files (should contain no exceptions)
  • Test for Linux, OS X, Windows (for Windows as far as possible, not all scripts exist)
  • Shutdown and verify there are no exceptions in the log output (after shutdown)
  • Check all start+submission scripts for paths with and without spaces (./bin/* scripts are quite fragile for paths with spaces)

Verify that the examples are running from both ./bin/flink and from the web-based job submission tool

  • Start multiple taskmanagers in the local cluster
  • Change the
  • Should be run on
    • local mode (start-local.sh)
    • cluster mode (start-cluster.sh)
    • multi-node cluster (can simulate locally by starting two taskmanagers)
    • The flink-conf.yml should to define more than one task slot
  • Results of job are produced and correct
  • Check also that Run the examples are running with the build-in data and external sources.with a parallelism > 1
  • Examine the log output - no error messages should be encounteredWeb interface shows progress and finished job in history
    Test on a cluster with HDFS.Check that a good amount of input splits is read locally (JobManager log reveals local assignments)
    Test against a Kafka installation
    Test the ./bin/flink command line client
  • Test "info" option, paste the JSON into the plan visualizer HTML file, check that plan is rendered
    • Test the parallelism flag (-p) to override the configured default parallelism
    Verify the plan visualizer with different browsers/operating systems
    Verify that the quickstarts for scala and java are working with the staging repository for both IntelliJ and Eclipse.
  • in particular the dependencies of the quickstart project need to be set correctly and the QS project needs to build from the staging repository (replace the snapshot repo URL with the staging repo URL)
  • The dependency tree of the QuickStart project must not contain any dependencies we shade away upstream (guava, netty, ...)
    • Test that quickstart archetypes are working on all platforms
    Run examples on a YARN cluster
    Run all examples from the IDE (Eclipse & IntelliJ)
    Run an example with the RemoteEnvironment against a cluster started from the shell script
    Pay special attention to new features
    Test recovery and exactly-once guarantees with master and worker failures @todo @uce Will update this with scriptsYARN (see 

Testing Larger Setups

These tests may require access to larger clusters or a public cloud budget. Below are suggestions for common things to test.

A nice program to use for tests is https://github.com/apache/flink

...

/tree/master/flink-end-to-end-tests/flink-datastream-allround-test
It uses built-in data generation and verification and uses some sensitive features.

Test against different file systems (Local/NFS, HDFS, S3, ...)

  • Use file systems for checkpoints
  • Use file systems for input/output

Run examples on different resource infrastructures

  • YARN
  • Mesos
  • Kubernetes

Test against different source and sink systems (Kafka, Kinesis, etc.)

Checking

...

  • 2.3.0 <= version < 2.4.0
    • Set yarn.application-attempts for Flink
    • Set yarn.resourcemanager.am.max-attempts for YARN (upper bound on number of failures)
    • Note: it's expected for these Hadoop versions that all containers are killed when the application master fails
  • 2.4.0 <= version < 2.6.0
    • Important: in this version the task manager containers should stay alive when the application master is killed
  • 2.6.0 <= version
    • Check that the application is only killed by YARN after the system has seen the maximum number of application attempts during one interval

...

  • Start multiple JobManager and TaskManager instances
  • Kill random instances (make sure that enough task slots and standby job managers are available)

...

Documentation

  • Check that all links work, the front page is up to date

  • Check that new features are documented and updates to existing features are written down.

  • Ensure that the migration guide from the last release to the new release is available and up to date.