+1 (binding). But I have one possible improvement proposal (this might be done as a later amendment if we find good support).
I am a little concerned about the migration "stage" when some "airflow" commands will raise deprecations, some will be missing, some will be still there (but are going to be removed) and some will be there without plans to be removed. This might get people really confused on what they should use to run some commands. I think we would still get exactly same benefits for maintenance, if we do NOT deprecate nor remove `airflow` commands from "airflow" CLI at all - but simply **silently** redirect them to airflowctl under the hood (airflowctl will have to become a dependency of `airflow-core`). The authentication could then be done "on the flight" - without even the user storing any user:password locally - `airflow` could dynamically generate a token for the remote call (it already has all the necessary config to do so). This way we would not have to have dedicated users created and user/passwords stored locally for "airflow" commands to work - essentially keeping **exactly** the same behaviour of "airflow cli" when you run them on the "airflow-core" machine. Documentation could be generated from that single source of truth in airflow-ctl (but otherwise it would remain the same for all the remote "airflow" commands). It would then be just a technical change from directly calling python API for the CLI commands into running airflow-ctl local HTTPS API calls but for users things would remain the same. I think it has **exactly** the same benefits (no redundancy in command maintenance). And it might ease the learning process (basically NO learning needed at all - everything will work exactly the same as today) - and allow truly incremental migration. And there is no need whatsoever in this case to remove the "airflow" commands. They will **just work** as if `airflowclt` was called. We are **anyhow** going to have "airflow" cli for the local admin tasks, so the CLI needs to be there, I see generally no drawback in leaving the "empty shell" airflow commands to call airflow-ctl automagically. I think it would be super convenient for the person who does admin tasks on "airflow-core" to run the same "airflow" CLI for all kinds of commands rather than remembering which ones are in "airflow-ctl" and which ones are in "airflow" CLI. Again - not a blocker and this is still my +1 for the original proposal - but maybe a good opportunity to get the voting people (and Buğra of course) to say what they think about this kind of "amendment". J. On Tue, Jan 27, 2026 at 9:07 PM Jens Scheffler <[email protected]> wrote: > +1 (binding) > > On 27.01.26 20:16, Buğra Öztürk wrote: > > Hey all, > > > > I would like to call a vote on this AIP > > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=382175838 > > > > The previous discussion thread was > > https://lists.apache.org/thread/rgbbl8dt79nt455mh62m34dcj2b9s0lb > > > > Based on the discussion on AIP-81 > > < > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-81+Enhanced+Security+in+CLI+via+Integration+of+API > >, > > this has already been agreed upon as a plan. > > We have a more concrete plan to reduce the impact on users as much as > > possible on AIP-94. > > It is not a child AIP. It contains two different projects, which include > a > > tooling and a plan for migration from Airflow CLI (Remote Commands, see > > AIPs) to Airflow CTL (airflowctl). > > > > Thank you to everyone who commented on the AIP and responded to the > > discussion thread! > > > > The vote will run for 5 days and last till next Sunday, the 1st of > February > > 2026 21:00 CET. > > > https://www.timeanddate.com/countdown/election?iso=20260201T21&p0=16&msg=%5BVOTE%5D+AIP-94&font=cursive > > > > Everyone is encouraged to vote, although only PMC members' and > Committers' > > votes are considered binding. > > > > Please vote accordingly > > > > [ ] +1 Approve > > [ ] +0 no opinion > > [ ] -1 disapprove with the reason > > > > Please consider this is my +1 binding :) > > > > Regards, > > Bugra Ozturk > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
