SEZ9 commented on issue #12457: URL: https://github.com/apache/seatunnel/issues/12457#issuecomment-5843395180
Thanks for turning the umbrella discussion into a concrete STIP. I agree with the direction: today `DeployType` already lists YARN and KUBERNETES, but the `YarnResourceManager` / `KubernetesResourceManager` create/release methods are placeholders returning null, so there is no native application-mode path to extend yet. That makes the lifecycle contract the most important part of this proposal, not the module layout. The linked implementation PR has grown well beyond a design artifact (root resource-manager modules, provider SDK and distribution work, engine/starter changes, two platform implementations, POM changes, E2E, CI, and large EN/ZH docs), and its build is reported as failing above. I don't think we can review or accept that as a single MVP. Please keep the STIP and the PR blocked until the following is addressed: 1. **YARN-first v1.** Keep Kubernetes in the STIP as a design comparison, but make it a separately reviewed follow-up. The first acceptance should not depend on two platform SDKs, two packaging paths, or two E2E environments. 2. **Migration story for the existing placeholders.** Spell out how the current engine third-party `ResourceManager` placeholders relate to the proposed `ResourceManagerDriver`. There should be one owner for external worker allocation, release, retries, and terminal cleanup, with the call sequence and compatibility boundary written down rather than two competing abstractions. 3. **Freeze the YARN contract first.** Before new modules or POM changes proceed, the STIP should define: submission/rollback ownership, worker-registration deadline, detached status/cancel semantics, stable Option names and defaults, checkpoint restore identity, and behavior when the AM or a worker exits. 4. **Reviewable slices after the contract.** Shared interface plus YARN-only launcher/driver first, then real MiniYARN/HDFS lifecycle and restore evidence. Kubernetes, distribution expansion, and any SDK/shading decisions should follow their own approved contract. Also, please confirm in the STIP that the existing standalone, Flink, and Spark entrypoints remain unchanged. Concrete asks: update the STIP text and the PR description to state this split, link the focused follow-up work, and avoid describing the PR as implemented while its CI is not green. Once the YARN contract section is in place I'm happy to do a detailed pass on it. <!-- streview-comment:1333 --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
