Hi Jason, Thanks for putting these together with the amazon PRs as a template.
I'd like to take #70270 (hdfs). I've commented on the sub-issue to claim it. I'll verify end to end against a local single-node Hadoop/WebHDFS container, so no external account is needed on my side. Could you please reach out to me now if you have any questions or concerns? Thank you. On Wed, Jul 22, 2026 at 10:15 PM Yuseok Jo <[email protected]> wrote: > Hi Jason, > > Thanks for sharing this opportunity. > > I'd like to work on #70271 and #70272. > > Thanks, > Yuseok Jo > > > 2026년 7월 23일 (목) 오후 2:09, Aaron Chen <[email protected]>님이 작성: > > > Hi Jason, > > > > Thanks for sharing this great opportunity. > > > > I can work on #70266 <https://github.com/apache/airflow/issues/70266> > and > > #70267 <https://github.com/apache/airflow/issues/70267>. I have a GCP > > account I can use for end-to-end verification. > > > > Best, > > Aaron > > > > On Thu, Jul 23, 2026 at 1:00 PM Zhe-You(Jason) Liu <[email protected]> > > wrote: > > > > > Hi all, > > > > > > I would like to share a contribution opportunity that came out of the > > > recent remote logging refactoring effort — it is a set of small, > > > well-scoped tasks, and any help would be greatly appreciated. > > > > > > Some context: PR #67056 [1] decoupled remote logging from the hardcoded > > > if/elif chain in airflow_local_settings.py. Core and the Task SDK now > > > resolve the remote log handler through ProvidersManager dispatch on the > > URL > > > scheme of [logging] remote_base_log_folder, instantiating the provider > > > class via a no-arg from_config() classmethod. The old chain remains as > a > > > transitional fallback until every backend has been migrated. > > > > > > The amazon provider has already been migrated and serves as a template > > (s3: > > > #69817 [2], cloudwatch: #69816 [3]). Seven backends remain, each > tracked > > by > > > its own sub-issue: > > > > > > - gs (google) > > > https://github.com/apache/airflow/issues/70266 > > > - stackdriver (google) > > > https://github.com/apache/airflow/issues/70267 > > > - wasb (microsoft.azure) > > > https://github.com/apache/airflow/issues/70268 > > > - oss (alibaba) > > > https://github.com/apache/airflow/issues/70269 > > > - hdfs (apache.hdfs) > > > https://github.com/apache/airflow/issues/70270 > > > - elasticsearch > > > https://github.com/apache/airflow/issues/70271 > > > - opensearch > > > https://github.com/apache/airflow/issues/70272 > > > > > > The meta issue with the full pattern and per-backend notes: #70265 [4] > > > > > > Each migration has four parts: > > > 1. add a from_config() classmethod mirroring the existing branch in > > > airflow_local_settings.py > > > 2. register the scheme in the provider's provider.yaml / > > > get_provider_info.py > > > 3. add tests following the merged amazon examples > > > 4. verify end to end against a real backend that you set up yourself > and > > > share the screenshot on the PR. > > > > > > If you would like to pick one up, please comment on the sub-issue to > > claim > > > it. > > > > > > As for the next steps: my plan is to wait until all the provider > > migrations > > > are merged and released, then add a deprecation warning in core for the > > > legacy path, gated on the provider versions that ship from_config, and > > > finally remove the hardcoded remote logging config in a future minor or > > > major release (whichever the community prefers). I will bring those > steps > > > to the list for discussion when we get there. Together, **these steps > > will > > > finally clean up a provider coupling in core that has lived there for > > > almost a decade**. > > > > > > Thank you all in advance for your contributions! > > > > > > Best regards, > > > Jason > > > > > > [1] https://github.com/apache/airflow/pull/67056 > > > [2] https://github.com/apache/airflow/pull/69817 > > > [3] https://github.com/apache/airflow/pull/69816 > > > [4] https://github.com/apache/airflow/issues/70265 > > > > > > -- Thanks and Regards, Ramachandra Nalam
