+ 1 (binding) I also like Jarek's proposal. airflow CLI is way too powerful to expose to the average user and ctl approach is best. However we shouldn't restrict admins in a way that they need install ctl to access api supported commands.
A good example is local development with airflow standalone, there is no need to have a seperate airflowctl configured for your scratch dev environment. (+2 for Jareks suggestion :D) On Tue, Jan 27, 2026 at 3:34 PM Jarek Potiuk <[email protected]> wrote: > +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] > > > > >
