shivaam commented on code in PR #65958: URL: https://github.com/apache/airflow/pull/65958#discussion_r3295124847
########## task-sdk/src/airflow/sdk/coordinators/java/coordinator.py: ########## @@ -0,0 +1,261 @@ +# +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +"""Java runtime coordinator that launches a JVM subprocess for Dag file processing and task execution.""" + +from __future__ import annotations + +import email +import os +import pathlib +import selectors +import socket +import subprocess +import time +import zipfile +from typing import TYPE_CHECKING, cast + +import attrs +import psutil +import structlog + +from airflow.sdk.execution_time.coordinator import BaseCoordinator +from airflow.sdk.execution_time.supervisor import ActivitySubprocess + +if TYPE_CHECKING: + from collections.abc import Sequence + + from structlog.typing import FilteringBoundLogger + from typing_extensions import Self + + from airflow.sdk.api.client import Client + from airflow.sdk.api.datamodels._generated import BundleInfo + from airflow.sdk.execution_time.workloads.task import TaskInstanceDTO + +log: FilteringBoundLogger = structlog.get_logger(logger_name="coordinators.java") + + +def _start_server() -> socket.socket: + server = socket.socket() + server.bind(("127.0.0.1", 0)) + server.setblocking(True) + server.listen(1) # Just need to listen to the child process. + return server + + +def _calculate_classpath(jars_root: Sequence[pathlib.Path]) -> str: + jars = (p.as_posix() for root in jars_root for p in root.iterdir() if p.suffix == ".jar") + return os.pathsep.join(jars) + + [email protected] +class _MainJar: + path: pathlib.Path + main_class: str + schema_version: str | None + + @classmethod + def find(cls, jars_root: Sequence[pathlib.Path]) -> Self: + for root in jars_root: + for p in root.iterdir(): + if p.suffix != ".jar": + continue + with zipfile.ZipFile(p) as zf: + with zf.open("META-INF/MANIFEST.MF") as f: + manifest = email.message_from_binary_file(f) + if main_class := manifest["Main-Class"]: + return cls(p, main_class, manifest.get("Airflow-SDK-Supervisor-Schema-Version")) + resolved_paths = os.pathsep.join(str(p.resolve()) for p in jars_root) + raise FileNotFoundError(f"cannot fine main class in {resolved_paths}") Review Comment: @uranusjr I like the idea of passing the entrypoint path to the coordinator. This is also the direction I am taking for the TS SDK. Thinking about this from the user journey, ideally the experience for any SDK should be close to Python and simple for users, without requiring them to understand Airflow/SDK internals: ``` - Import the SDK - Define Dags/tasks - Build/package with the team's existing tooling - Point Airflow at the entrypoint/executable - Airflow and the SDK figure out the rest ``` From that perspective, users will naturally provide `dag_id` and `task_id` when they define DAGs/tasks through the SDK APIs, but I’m not sure they should also need to duplicate that information in a separate bundle manifest/comment/footer as part of the baseline flow. The supervisor schema version feels even more like an SDK/runtime concern, since it is tied to the SDK version rather than the user’s DAG code. For the simple path, could the entrypoint be the only thing a user has to provide? The SDK/runtime already knows how to expose Dag/task information, and the supervisor schema version can be a property of the SDK/runtime version rather than something the user should maintain in bundle metadata. Bundle metadata can still be useful as an optimization for power users. My main concern is adoption: most teams already have CI, and internal build tools, and deployment conventions. If the first step for non-Python SDKs is "use this Airflow-specific packer/manifest format," we may be adding friction before users can even try the model. -- 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]
