Forgot to include the link again, here it is. https://cwiki.apache.org/confluence/x/XorHFg
Bugra Ozturk On Mon, 12 Jan 2026, 21:25 Buğra Öztürk, <[email protected]> wrote: > 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 >
