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

[FLINK-26252][runtime][test-utils] Refactor MiniClusterExtension to support JUnit 5 parallel tests #18847

Merged
merged 3 commits into from Feb 24, 2022

Conversation

slinkydeveloper
Copy link
Contributor

What is the purpose of the change

The goal of this PR is to fix MiniClusterWithClientExtension (renamed to MiniClusterExtension) to properly support parallel tests, to be used with the ExtendWith annotation and to correctly tie to the lifecycle when creating one cluster per class.

Brief change log

  • Reworked MiniClusterExtension to add support for parallel tests and injection of client as test parameters
  • Renamed MiniClusterExtension in flink-runtime to avoid confusion and misusages

@zentol zentol self-assigned this Feb 18, 2022
@flinkbot
Copy link
Collaborator

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Automated Checks

Last check on commit 7f3404d (Fri Feb 18 14:02:12 UTC 2022)

Warnings:

  • No documentation files were touched! Remember to keep the Flink docs up to date!

Mention the bot in a comment to re-run the automated checks.

Review Progress

  • ❓ 1. The [description] looks good.
  • ❓ 2. There is [consensus] that the contribution should go into to Flink.
  • ❓ 3. Needs [attention] from.
  • ❓ 4. The change fits into the overall [architecture].
  • ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.


The 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 commands
The @flinkbot bot supports the following commands:

  • @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
  • @flinkbot approve all to approve all aspects
  • @flinkbot approve-until architecture to approve everything until architecture
  • @flinkbot attention @username1 [@username2 ..] to require somebody's attention
  • @flinkbot disapprove architecture to remove an approval you gave earlier

@flinkbot
Copy link
Collaborator

flinkbot commented Feb 18, 2022

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build

@zentol
Copy link
Contributor

zentol commented Feb 21, 2022

The architecture tests are complaining because they don't recognize the MiniClusterExtension as a mini cluster without the CallbackWrappers.

@slinkydeveloper
Copy link
Contributor Author

@JingGe can you please check this out?

@slinkydeveloper slinkydeveloper force-pushed the FLINK-26252 branch 2 times, most recently from 9ce87b8 to 1cfeaa7 Compare February 22, 2022 14:48
@ruanhang1993
Copy link
Contributor

ruanhang1993 commented Feb 22, 2022

@slinkydeveloper , Thanks for your work.
MiniClusterWithClientExtension is aimed to replace the Junit 4 rule MiniClusterWithClientResource for Junit 5 miguration. The same is the MiniClusterExtension for MiniClusterResource. Because of some unresolved discussions, these extensions are only used in one or two classes as an example.

The MiniClusterWithClientResource rule could be used as @Rule or @ClassRule. In order to resolve conflicts, we introduce each/all wrappers for Junit 5 extensions. Maybe you can search the usages of MiniClusterWithClientResource. I think it is better to adapt @Rule and @ClassRule in Junit 5 when refactoring.

To be honest, I don't understand why the MiniClusterResource is used as a @Rule to start and end a mini cluster for every test cases.

@slinkydeveloper
Copy link
Contributor Author

I think it is better to adapt @rule and @ClassRule in Junit 5 when refactoring.
To be honest, I don't understand why the MiniClusterResource is used as a @rule to start and end a mini cluster for every test cases.

Exactly my point on why I didn't added this feature here. It doesn't seem there are much tests doing that, and probably most of the ones that are doing it, are doing it by mistake. I would rather not add the capability in this PR. If it's really needed, we add it in future, but now as default this extension always starts only one cluster per class. Another aspect is that if you really need to create a cluster per method, then just manually instantiating MiniCluster should be enough, and you don't need the extension doing it for you.

@zentol
Copy link
Contributor

zentol commented Feb 22, 2022

There are use-cases where it can make sense to run dedicated clusters for each test, for example when you add a taskmanager to the cluster within a test (test scale-up of a job), doing something destructive like killing a taskmanager (scala-down / recovery) or creating an intentional resource leak.
Mind you that that these things are easily possible since we expose the MiniCluster.

However, I'd consider these as niche use-cases that we shouldn't don't have to focus on (at this time). There are multiple ways to workaround this (spread tests across classes / wrap extension / manual life-cycling) in any case.

Copy link
Contributor

@zentol zentol left a comment

Choose a reason for hiding this comment

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

Running CI in the background; will update PR and merge once it's green.

Copy link
Contributor

@JingGe JingGe left a comment

Choose a reason for hiding this comment

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

Thanks @slinkydeveloper for driving this PR. It looks overall good. I just left some comments.


```
rm -rf `find . -type d -name archunit-violations`
mvn test -Dtest="*TestCodeArchitectureTest*" -DfailIfNoTests=false -Darchunit.freeze.refreeze=true -Darchunit.freeze.store.default.allowStoreCreation=true -Dfast
Copy link
Contributor

Choose a reason for hiding this comment

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

NIT: -Dskip.npm=true

* <p>2. For JUnit 5 test, use {@link ExtendWith}:
*
* <pre>{@code
* @ExtendWith(MiniClusterExtension.class)
Copy link
Contributor

Choose a reason for hiding this comment

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

Where to use it? at class level?

Copy link
Contributor

Choose a reason for hiding this comment

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

yes

@@ -135,14 +140,46 @@
MiniClusterWithClientResource.class, Rule.class));
}

private static DescribedPredicate<JavaClass> inFlinkRuntimePackages() {
return JavaClass.Predicates.resideInAPackage("org.apache.flink.runtime.*");
Copy link
Contributor

Choose a reason for hiding this comment

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

import static?

/**
* An extension which starts a {@link MiniCluster} for testing purposes.
*
* <p>This should only be used by tests within the flink-runtime module. Other modules should use
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you add more description to tell why a different MiniClusterExtension is required explicitly for flink-runtime and the same MiniClusterExtension can not be used by other modules? I think the idea of using @InjectMiniCluster is excellent and could be very useful for tests in other modules beyond flink-runtime too.

Copy link
Contributor

Choose a reason for hiding this comment

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

MiniClusterExtension requires flink-clients. InjectMiniCluster can also be used with the MiniClusterExtension.

zentol and others added 3 commits February 24, 2022 14:27
Certain configuration parameters (e.g., ports) are inferred from other extensions. As extensions commonly only really start up resources in before*() methods the current approach of determining the configuration up-front imposes limitations as to whether a MiniClusterExtension can be static or not.
With this change the configuration can also be passed in with a Supplier that is evaluated right before the cluster is started.
Refactors the test to make use of a static MiniClusterExtension, in preperation FLINK-26252.
@zentol zentol merged commit 8cdd0b8 into apache:master Feb 24, 2022
@slinkydeveloper slinkydeveloper deleted the FLINK-26252 branch March 1, 2022 08:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants