DanielLeens commented on issue #12457: URL: https://github.com/apache/seatunnel/issues/12457#issuecomment-5814907003
Classification: D / Zeta Application Mode architecture.\n\nThanks for turning the umbrella discussion into a concrete STIP. Current dev confirms the starting point: DeployType contains YARN and KUBERNETES, but the existing YarnResourceManager and KubernetesResourceManager create/release methods are placeholders returning null. There is no native application-mode path to extend.\n\nThe linked #12460 is no longer a design-only artifact: it introduces root resource-manager modules, provider SDK and distribution work, engine/starter changes, two platform implementations, POM changes, E2E, CI, and large EN/ZH documentation additions. Its Build is currently failed and the PR is BLOCKED. This cannot be accepted as one MVP implementation path.\n\nPlease keep the STIP and #12460 blocked while the work is reduced and the lifecycle contract is made reviewable:\n\n1. Make v1 YARN-first. Keep Kubernetes as a design comparison and a later, separately reviewed implementation; do not make the fir st acceptance depend on two platform SDKs, packaging paths, or E2E environments.\n2. Specify the migration relationship between the existing engine third-party ResourceManager placeholders and the proposed ResourceManagerDriver. There must be one owner for external worker allocation, release, retries, and terminal cleanup; spell out the call sequence and compatibility boundary rather than leaving two competing abstractions.\n3. Freeze the YARN contract before new modules or POM changes proceed: submission/rollback ownership, worker-registration deadline, detached status/cancel semantics, stable Option names/defaults, checkpoint restore identity, and the behavior when the AM or a worker exits.\n4. Split the implementation into reviewable slices after that contract: shared interface plus YARN-only launcher/driver, then real MiniYARN/HDFS lifecycle and restore evidence. Kubernetes, distribution expansion, and optional SDK/shading decisions must follow their own approved contract.\n\nTh e existing standalone, Flink, and Spark entrypoints must remain unchanged. Please update the STIP and PR description to state this split and link the focused follow-up work; do not represent #12460 as implemented while its CI is failing. -- 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]
