-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
[improve][fn] Allow unknown fields in connectors config #20116
Conversation
...ctions/instance/src/main/java/org/apache/pulsar/functions/instance/JavaInstanceRunnable.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
if (configClass != null) { | ||
final Object configInstance = Reflections.createInstance(configClass, | ||
Thread.currentThread().getContextClassLoader()); | ||
final List<String> allFields = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure that this is correct.
ObjectMapper should follow Java Beans conventions and use getter/setters together with public fields.
We should use some ObjectMapper utilities here in order to ensure that we are doing the right thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've found a way to use the same deserializer used by jackson mapper, so this should cover all the cases when jackson mapper is used by the sink/source
|
||
for (String s : config.keySet()) { | ||
if (!allFields.contains(s)) { | ||
log.warn("Field '{}' not defined in the {} configuration {}, the field will be ignored", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this should be logged as "ERROR", WARNINGs tend to be ignored by alert systems
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
+ "Ignoring unknown fields makes possible to keep the new configuration and " | ||
+ "only rollback the connector." | ||
) | ||
private boolean ignoreUnknownConfigFields = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This configuration applies to the instances of the functions/connectors, and not to the function worker (that already ignores unknown fields)
what about 'functionsIgnoreUnknownConfigFields' ? (maybe we can do better, but connectors are actually functions)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that and I agree. But there are other properties that are meant to be used by the java runner like
maxPendingAsyncRequests, exposeAdminClientEnabled, additionalJavaRuntimeArguments so I'd prefer to stick with this convention
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
LGTM
(cherry picked from commit f7c0b3c)
Motivation
Most of the java connectors (sinks and sources) map the configuration to a java class. Pulsar exposes a method to convert the configuration (
IOConfigUtils#loadWithSecrets
) using a jackson mapper. However is up to the connector to decide how to convert the configuration.Most of the builtin java connectors do not allow unknown fields in their configuration. This is usually a good thing since it alerts the user that something is malconfigured. But this doesn't leave space for connectors' rollbacks.
The scenario which is not possible to cover is:
Modifications
ignoreUnknownConfigFields
(default false) that strips out fields not supported in the current sink/source config. The sink/source config class is retrieved from the service definition (sinkConfigClass
andsourceConfigClass
)Verifying this change
Documentation
doc
doc-required
doc-not-needed
doc-complete
Matching PR in forked repository