alexandrefimov commented on issue #7511: URL: https://github.com/apache/kyuubi/issues/7511#issuecomment-5174822300
Hi @turboFei, I'd like to work on this. I read #7510 and the older #6642. There are three things I'd like to settle before touching code: 1. Should Kyuubi only authenticate and pin a Connect session to an engine, while the client and engine keep ownership of `session_id`, `server_side_session_id`, `operation_id`, and reattach state? #7510 also maps this state into `SessionManager` and `OperationManager`, which makes Kyuubi part of the Connect state machine. 2. Should plan-level authorization stay in the Spark engine, or should Kyuubi inspect and authorize DataFrame plans before forwarding them? 3. Should #7510 be used as the design baseline, or only as background? Was it closed for any reason that should affect new work? For v1, my preference is a thin proxy: one exact client/engine protocol line, no `ExecutePlan` replay after an ambiguous disconnect, and no reattach to another engine. Kyuubi would own authentication, routing, limits, and audit; Spark would own plan execution and operation state. If that matches the intended boundary, I can update the design from #7510 and split the work into reviewable PRs. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
