jason810496 commented on PR #54582: URL: https://github.com/apache/airflow/pull/54582#issuecomment-3197757508
I understand your point, and I agree that in Airflow 3 we should not have access to the database. If I am not mistaken about the purpose of the `eks_get_token` module, it is designed to be called directly with the Python executable, rather than being initialized through TaskSDK. Since it is executed by Python directly, and not within executor, triggerer, or similar processes, it operates outside the typical Airflow runtime. https://github.com/apache/airflow/blob/9b46d76ee4fffdbefa7fa14aba5b7d8a8ec15f3b/providers/amazon/src/airflow/providers/amazon/aws/hooks/eks.py#L81-L83 The `EksHook` here represents a special case, as it is invoked by a shell command such as: ```sh sh -c output=$({python_executable} -m airflow.providers.amazon.aws.utils.eks_get_token --cluster-name {eks_cluster_name} {args} 2>&1) ... ``` Therefore, if we truly want to eliminate database access when retrieving connections in the context of `EksHook`, it seems necessary to introduce a provider-specific (or connection-specific) `CommsDecoder` for obtaining connection credentials via TaskSDK. Since initialization of `SUPERVISOR_COMMS` occurs within the `task_runner`, it may be possible to initialize `SUPERVISOR_COMMS` within the `main` function of the `eks_get_token` module. This approach could resolve the error without requiring database access. -- 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]
