jason810496 commented on code in PR #67056: URL: https://github.com/apache/airflow/pull/67056#discussion_r3263675278
########## airflow-core/newsfragments/67056.significant.rst: ########## @@ -0,0 +1,101 @@ +Decouple remote logging resolution from ``airflow.logging_config`` + +Remote task log handler resolution is now owned by the shared +``airflow_shared.logging.factory`` module and applies a single, well-defined +precedence rule. ``airflow.logging_config.load_logging_config`` is deprecated: +loading the ``[logging] logging_config_class`` dict and resolving the remote +handler are now two independent steps. + +**Resolution order (``resolve_remote_task_log``):** + +1. **User-defined ``[logging] logging_config_class``** — if the user has set + ``logging_config_class`` to a custom module path, and that module exports a + ``REMOTE_TASK_LOG`` (or ``DEFAULT_REMOTE_CONN_ID``) attribute, those values + win. Existing custom logging configs keep working unchanged. +2. **ProvidersManager scheme dispatch** — the scheme of ``[logging] + remote_base_log_folder`` (e.g. ``s3``, ``gs``, ``wasb``) is looked up in the + provider yaml ``remote-logging:`` registry. The matching ``RemoteLogIO`` + class is imported and instantiated via its ``from_config()`` classmethod. + The connection id comes from ``[logging] remote_log_conn_id`` (set + explicitly by the user; providers needing a backend default can read it + inside ``from_config``). +3. **Legacy attr-path fallback** — if neither of the above produced a handler, + the resolver imports the default logging module + (``airflow.config_templates.airflow_local_settings``) and reads its + ``REMOTE_TASK_LOG`` / ``DEFAULT_REMOTE_CONN_ID`` attributes. This is the + per-scheme ``if/elif`` chain in ``airflow_local_settings.py`` and is + transitional — it will be removed once every in-tree provider exposes + ``from_config``. Review Comment: Make sense, explicitly mention Airflow 4 in the new fragments. ########## airflow-core/newsfragments/67056.significant.rst: ########## @@ -0,0 +1,101 @@ +Decouple remote logging resolution from ``airflow.logging_config`` + +Remote task log handler resolution is now owned by the shared +``airflow_shared.logging.factory`` module and applies a single, well-defined +precedence rule. ``airflow.logging_config.load_logging_config`` is deprecated: +loading the ``[logging] logging_config_class`` dict and resolving the remote +handler are now two independent steps. + +**Resolution order (``resolve_remote_task_log``):** + +1. **User-defined ``[logging] logging_config_class``** — if the user has set + ``logging_config_class`` to a custom module path, and that module exports a + ``REMOTE_TASK_LOG`` (or ``DEFAULT_REMOTE_CONN_ID``) attribute, those values + win. Existing custom logging configs keep working unchanged. +2. **ProvidersManager scheme dispatch** — the scheme of ``[logging] + remote_base_log_folder`` (e.g. ``s3``, ``gs``, ``wasb``) is looked up in the + provider yaml ``remote-logging:`` registry. The matching ``RemoteLogIO`` + class is imported and instantiated via its ``from_config()`` classmethod. + The connection id comes from ``[logging] remote_log_conn_id`` (set + explicitly by the user; providers needing a backend default can read it + inside ``from_config``). +3. **Legacy attr-path fallback** — if neither of the above produced a handler, + the resolver imports the default logging module + (``airflow.config_templates.airflow_local_settings``) and reads its + ``REMOTE_TASK_LOG`` / ``DEFAULT_REMOTE_CONN_ID`` attributes. This is the + per-scheme ``if/elif`` chain in ``airflow_local_settings.py`` and is + transitional — it will be removed once every in-tree provider exposes + ``from_config``. Review Comment: Make sense, explicitly mention Airflow 4 in the newfragments. -- 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]
