Hi Constance and Jens, Thanks for the question! The case is exactly as Jens mentioned. Thanks for the details, Jens.
Yes Jens, you are right. We agreed that the remote command changes will replace the airflow CLI commands with the airflowctl ones. Since we decided to eliminate the dedicated version release tied to Core and TaskSDK, the Airflow CLI commands have already been released in version 3.0.0 and onwards. I thought it would be good to reconfirm how we want to proceed with user-facing changes, since users need some level of migration (that is already stated in AIP-81) even for 3.0.x versions. Additionally, having an agreed structured approach here would help set the right expectations for users while approaching it as a separate project, since we have both tools in place at the moment as code and will have them released at some point at the same time. How about I move this AIP under AIP-81 and make it like a sub-AIP? As we are doing in other AIPs, approaching one as an umbrella. Would that be the right approach in this case? On Tue, Sep 2, 2025 at 7:13 PM Jens Scheffler <j_scheff...@gmx.de.invalid> wrote: > Hi Constance. > > the airflow CLI is still needed for some admin commands which arequire > DB access as well is used to start the server components. > > One example is DB migration, DB Cleaning utils. This can not be a remote > command (chicken and egg problem). > > But all (admin) commands which can be run from remote and do not need > direct DB access are the ones that are proposed for airflowctl. > > The overview and definition of different command types was described in > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315493347#AIP81EnhancedSecurityinCLIviaIntegrationofAPI-Considerations > > Actuelly I thought from my memory that the deprecation and removal was > agreed already in AIP-81 - but of course we can re-discuss if it was not > covered there. > > Jens > > On 02.09.25 17:41, Constance Martineau wrote: > > Hi Buğra, > > > > For my own knowledge: Is the goal to eventually fully deprecate the > Airflow > > CLI in favour of airflow-ctl? > > > > Constance > > > > On Sun, Aug 31, 2025 at 1:02 PM Buğra Öztürk <ozturkbugr...@gmail.com> > > wrote: > > > >> Hi all, > >> > >> As many of you know, airflowctl is on the way for its 1.0.0 release > step by > >> step and has already been stated as a dependency in AIP-94. Building on > >> that, I have drafted a new Airflow Improvement Proposal: Decouple Remote > >> Commands from airflow CLI (to airflowctl). > >> > >> Today, many airflow CLI commands duplicate functionality that already > >> exists in the Public API/airflowctl. This results in: > >> > >> - > >> > >> Duplicate development effort (API + CLI both need maintenance), > >> - > >> > >> Security risks (CLI can directly interact with the metadatabase, > >> bypassing RBAC), > >> - > >> > >> Inconsistent user experience (differences between CLI and API > >> behaviour). > >> > >> With this AIP, the goal is to: > >> > >> - > >> > >> Deprecate Remote commands in the airflow CLI, > >> - > >> > >> Provide equivalent functionality in a dedicated API-driven tool: > >> airflowctl, > >> - > >> > >> Ensure all Remote operations go through the API, strengthening RBAC > and > >> auditability*.* > >> - > >> > >> Keep airflow CLI for local administrative commands only (e.g., db > shell, > >> process management). > >> > >> This will simplify maintenance, improve security, and give users a > clearer > >> separation between local vs. remote operations. > >> > >> Full details are in the proposal in Confluence: > >> https://cwiki.apache.org/confluence/x/XorHFg > >> > >> I would love to hear your thoughts, feedback, and concerns. > >> > >> Thanks, > >> -- > >> Bugra Ozturk > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > > -- Bugra Ozturk
