Hey team, I want to revive the discussion one more time for the AIP to go for voting soon, fingers crossed. I decuttered all the additional information and made the AIP simpler. I have addressed a couple of comments and ideas from meetings. I have added a tool for migration. I added a clear set of steps to answer when and how the decoupling will happen. The AIP will be two-phase, but can be run in parallel. While the airflowctl improvements continue, I would like to give this one a start to parallelise some workstreams. Any feedback or ideas would be appreciated. Regards,
On Tue, Sep 2, 2025 at 8:22 PM Buğra Öztürk <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > -- > Bugra Ozturk > -- Bugra Ozturk
