moomindani commented on issue #39262: URL: https://github.com/apache/airflow/issues/39262#issuecomment-5143164935
This has been idle since May 2024, with the original question about scope never answered. Two things suggest closing rather than reviving it. **What this issue targets is deprecated.** Per [the DBFS docs](https://docs.databricks.com/aws/en/dbfs/), "Both DBFS root and DBFS mounts are deprecated and not recommended by Databricks" — and those are exactly what the [DBFS API](https://docs.databricks.com/api/workspace/dbfs) this issue proposes wrapping is used to read and write. Building a new operator surface on top of that would point users at a path Databricks steers away from. Worth being precise, though: this is not a blanket deprecation of DBFS as a concept — the `dbfs:` URI scheme remains central, and disabling root/mounts does not disable the URI itself. It is the storage locations this API operates on that are deprecated, not the identifier. **There is no demand signal.** This is the only DBFS issue in the repo, and I could not find any request for Unity Catalog volumes file operations either — no issues, no PRs. So nothing indicates users are blocked on either API. If someone does need volumes file operations later, Airflow's `ObjectStoragePath` / fsspec integration (declared via `filesystems:` in `provider.yaml`, as amazon, google, and sftp do) may fit better than a bespoke operator set, since volumes expose a `/Volumes/<catalog>/<schema>/<volume>/...` path model. That would be a fresh issue with a concrete use case behind it, not this one. Suggest closing as stale/superseded. --- Drafted-by: Claude Code (Opus 5); reviewed by @moomindani before posting -- 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]
