[FLINK-11781][yarn] Remove "DISABLED" as possible value for yarn.per-job-cluster.include-user-jar#7883
Conversation
|
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:
|
|
|
||
| /** @see YarnConfigOptions#CLASSPATH_INCLUDE_USER_JAR */ | ||
| public enum UserJarInclusion { | ||
| DISABLED, |
There was a problem hiding this comment.
We should check where this is parsed to the enum and throw a meaningful exception explaining that DISABLED has been removed.
There was a problem hiding this comment.
From Flink 1.5 to 1.7:
- If
DISABLEDis set, the job keeps failing. - If an invalid value is set, the default value (
ORDER) is used, and a warning is logged ("Configuration parameter {} was configured with an invalid value {}. Falling back to default ({}).").
If we would apply the PR as is, we would always log a warning (because DISABLED will be considered an invalid value). You are proposing to throw an exception with a customized message if DISABLED is set. This would help users that are upgrading from 1.4 to 1.8 directly. So I could do that but I think it makes sense to also propagate the exception for all other invalid values instead of logging a warning. What do you think?
There was a problem hiding this comment.
+1 for throwing exception rather than just logging, when mismatch.
d157650 to
af3e742
Compare
dawidwys
left a comment
There was a problem hiding this comment.
One thing we should fix is the case sensitivity for Configuration#getAsEnum other than that I had just small suggestions. Overall it looks good.
Personally I like the approach that if a user configures the option, it has to be set correctly (or otherwise an exception will be thrown). This way we won't fallback silently to some other option in case of e.g. spelling mistake. So +1 for current behavior.
|
|
||
| final String configValue = getString(configOption); | ||
| try { | ||
| return T.valueOf(enumClass, configValue); |
There was a problem hiding this comment.
nit:
| return T.valueOf(enumClass, configValue); | |
| return Enum.valueOf(enumClass, configValue); |
There was a problem hiding this comment.
I think that's better. Fixed it.
| * be parsed as a value of the provided enum class. | ||
| */ | ||
| @PublicEvolving | ||
| public <T extends Enum<T>> T getAsEnum( |
There was a problem hiding this comment.
nit: This would be more consistent with other getters.
| public <T extends Enum<T>> T getAsEnum( | |
| public <T extends Enum<T>> T getEnum( |
There was a problem hiding this comment.
I think you are right. It differs a bit though in the sense that ConfigOption<Enum> is not possible. On the other hand there is getBytes
There was a problem hiding this comment.
I see... then I am ok with both actually.
| } catch (final IllegalArgumentException | NullPointerException e) { | ||
| final String errorMessage = String.format("Value for config option %s must be one of %s (was %s)", | ||
| configOption.key(), | ||
| Arrays.asList(enumClass.getEnumConstants()), |
There was a problem hiding this comment.
nit:
| Arrays.asList(enumClass.getEnumConstants()), | |
| Arrays.toString(enumClass.getEnumConstants()), |
| configuration.getAsEnum(TestEnum.class, validOption); | ||
| fail("Expected exception not thrown"); | ||
| } catch (IllegalArgumentException e) { | ||
| final String expectedMessage = "Value for config option " + |
There was a problem hiding this comment.
nit: Personally prefer the approach with @Rule
@Rule
public ExpectedException thrown = ExpectedException.none();
@Test
public testMethod() {
...
thrown.expect(IllegalArgumentException.class);
thrown.message(....);
}
There was a problem hiding this comment.
Current solution is legible, and frequently used in Flink and elsewhere. I'll leave it as is.
| true); | ||
| fail("Expected exception not thrown"); | ||
| } catch (final IllegalArgumentException e) { | ||
| assertThat(e.getMessage(), containsString("cannot be set to DISABLED anymore")); |
There was a problem hiding this comment.
nit: As before -> I prefer the @Rule approach.
|
|
||
| final String configValue = getString(configOption); | ||
| try { | ||
| return T.valueOf(enumClass, configValue); |
There was a problem hiding this comment.
Shouldn't we call toUpperCase on configValue? At least for the scope of yarn.per-job-cluster.include-user-jar we tried to be case insensitive so far, which seems fair.
There was a problem hiding this comment.
You are right. I added a test case for this.
|
@flinkbot approve-until architecture |
|
@flinkbot approve all +1 LGTM |
…job-cluster.include-user-jar Remove this feature because it is broken since Flink 1.5 This closes apache#7883.
…job-cluster.include-user-jar Remove this feature because it is broken since Flink 1.5 This closes apache#7883.
|
Thanks for the review @dawidwys. Merging as soon as build is green. |
…job-cluster.include-user-jar Remove this feature because it is broken since Flink 1.5 This closes apache#7883.
…job-cluster.include-user-jar Remove this feature because it is broken since Flink 1.5 This closes apache#7883.
…job-cluster.include-user-jar Remove this feature because it is broken since Flink 1.5 This closes apache#7883.
What is the purpose of the change
This removes
DISABLEDas a possible value for the config optionyarn.per-job-cluster.include-user-jar. Since Flink 1.5, this feature is broken.Brief change log
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
@Public(Evolving): (yes / no)Documentation