-
Notifications
You must be signed in to change notification settings - Fork 13.9k
Release 1.6 #8406
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
Closed
Closed
Release 1.6 #8406
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes it can happen that Netty does not properly initialize the channel pipeline when sending a request from the RestClient. In this situation, we need to fail the response so that the caller will be notified about the un- successful call.
This adds tests to verify that jobs can be cancelled properly when there are standby masters. To enable this, we added tests to install Flink as a standalone cluster. The first two DB nodes will be running the master processes, while the others are running the TaskManagers. All Flink processes are supervised by runit – this allows killing for Flink processes by the nemesis. The client now implements a cancel operation. The model used by the checker had to be rewritten to address the fact that the job can be canceled. The cancel operation is "reliable", i.e., it either cancels the job successfully, or it fails the whole test fatally. This way we can be that the job should be eventually not running if the cancel operation completes successfully. This closes #6712.
Dynamic arguments hould be prefixed with -D. Despite that the config key is not needed because it is set in the flink-conf.yaml already.
Previously the Mesos tests were disabled due to FLINK-9936, which is resolved now. There are currently no known issues with Mesos so it is justified to enable the tests.
…daloneJobClusterEntrypoint This closes #6733.
Update the common methods to the new testing harness.
…ycle of ScalarFunction This closes #6771.
…ints by configuration [FLINK-10371][tests] Regenerate configuration docs [FLINK-10371] Adapt to code review This closes #6727.
…ink/docker-entrypoint.sh
…ger.sh script. jobmanager.sh script syntax changed in Flink 1.5 as documented here: https://ci.apache.org/projects/flink/flink-docs-stable/release-notes/flink-1.5.html#changed-syntax-of-jobmanagersh-script
…L example for Java. This closes #6790.
…dation. This closes #6775.
Logging configuration was set only for scala-shell in yarn mode. This commit sets the configuration for local and remote mode in start-scala-shell.sh script as well.
…location This commit removes container requests after containers have been allocated. This prevents that we will request more and more containers from Yarn in case of a recovery. Since we cannot rely on the reported container Resource, we remove the container request by using the requested Resource. This is due Yarn's DefaultResourceCalculator which neglects the number of vCores when allocating containers.
…in job defination This closes #7436
Added check if minikube is running. If it is not we try to start it couple of times. If we do not succeed we fail with a descriptive message.
…linkKafkaConsumerBase
…cle verifications
…before closed when concurrently accessed
…LifeCycle Split #testConsumerLifeCycle into two methods which represent the two if-else branches. This closes #7606.
…izedTaskInformation in class TaskDeploymentDescriptor
…ng file in Hadoop.
…g file in Hadoop.
…ough finished batch query This closes #7265.
The cause of the instability seems to be that due to a not-so-rare timing, the thread that calls the `interrupt()` on the main thread, runs still after its original test finishes and calls `interrupt()` during execution of the next test. This causes the normal execution (or `sleep()` in this case) to be interrupted.
Collaborator
|
Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community Review Progress
Please see the Pull Request Review Guide for a full explanation of the review process. DetailsThe Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required Bot commandsThe @flinkbot bot supports the following commands:
|
Member
|
@magic20191 Could you please close this pr, this pr wants to merge release-1.6 into master, which is unneeded |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the purpose of the change
(For example: This pull request makes task deployment go through the blob server, rather than through RPC. That way we avoid re-transferring them on each deployment (during recovery).)
Brief change log
(for example:)
Verifying this change
(Please pick either of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)
Does this pull request potentially affect one of the following parts:
@Public(Evolving): (yes / no)Documentation