Dennis-Mircea Ciupitu created FLINK-40106:
---------------------------------------------
Summary: Move FlinkResourceValidator and FlinkResourceMutator to
the api module
Key: FLINK-40106
URL: https://issues.apache.org/jira/browse/FLINK-40106
Project: Flink
Issue Type: Improvement
Components: Kubernetes Operator
Affects Versions: kubernetes-operator-1.15.0
Reporter: Dennis-Mircea Ciupitu
h1. Summary
Move the {{FlinkResourceValidator}} and {{FlinkResourceMutator}} plugin
interfaces from the {{flink-kubernetes-operator}} module into the
{{flink-kubernetes-operator-api}} module, so that all three resource plugin
SPIs (listener, validator, mutator) live in the api module and plugin authors
only need to depend on the api module.
h1. Motivation
The operator exposes three pluggable extension points that third parties
implement and register via the plugin mechanism:
* {{FlinkResourceListener}}
({{org.apache.flink.kubernetes.operator.api.listener}})
* {{FlinkResourceValidator}}
({{org.apache.flink.kubernetes.operator.validation}})
* {{FlinkResourceMutator}} ({{org.apache.flink.kubernetes.operator.mutator}})
{{FlinkResourceListener}} was intentionally moved into the api module under
FLINK-29655 so that listener implementations depend only on the stable,
lightweight api module rather than the full operator module.
{{FlinkResourceValidator}} and {{FlinkResourceMutator}} were not moved and
still live in the operator module, which is an inconsistency in the plugin SPI
surface.
As a result, anyone implementing a custom validator or mutator must depend on
the entire {{flink-kubernetes-operator}} module (controllers, reconcilers,
observers, services) even though the interfaces themselves only reference api
types. This is a heavier and less stable dependency than necessary for a plugin
author.
h1. Scope
Both interfaces are self-contained and only reference:
* {{org.apache.flink.core.plugin.Plugin}} (from {{flink-core}}, already a
dependency of the api module)
* api-module custom resource types: {{FlinkDeployment}}, {{FlinkSessionJob}},
{{FlinkStateSnapshot}}, {{AbstractFlinkResource}}
They carry no dependency on operator-module-internal types, so they can be
moved without pulling additional code into the api module, exactly as was done
for {{FlinkResourceListener}}.
The proposed target packages mirror the listener:
* {{org.apache.flink.kubernetes.operator.api.validation.FlinkResourceValidator}}
* {{org.apache.flink.kubernetes.operator.api.mutator.FlinkResourceMutator}}
h1. Benefits
* Consistent plugin SPI surface: all three resource plugin interfaces live in
the api module.
* Plugin authors depend only on the api module to implement a custom validator
or mutator, matching the listener experience.
* Cleaner module boundaries, the operator module keeps only the concrete
implementations and the discovery/wiring, not the public interface.
h1. Compatibility
Moving the interfaces changes their fully qualified class names, so this is a
breaking change for external validator and mutator implementations and their
{{META-INF/services}} plugin registration files, which must be updated to the
new package. This matches how FLINK-29655 handled the listener move (a clean
move without a compatibility shim) and should be called out in the release
notes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)