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)

Reply via email to