You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airflow.apache.org by Buğra Öztürk <oz...@gmail.com> on 2026/01/27 19:16:04 UTC
[VOTE] AIP-94 Decouple Remote Commands from airflow CLI (to airflowctl)
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
Re: [VOTE] AIP-94 Decouple Remote Commands from airflow CLI (to airflowctl)
Posted by Shahar Epstein <sh...@apache.org>.
+1 binding, implementing Jarek's proposal would be beneficial.
Shahar
On Tue, Jan 27, 2026 at 9:17 PM Buğra Öztürk <oz...@gmail.com>
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
>
Re: [VOTE] AIP-94 Decouple Remote Commands from airflow CLI (to airflowctl)
Posted by Dheeraj Turaga <dh...@gmail.com>.
+ 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 <ja...@potiuk.com> 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 <js...@apache.org>
> 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: dev-unsubscribe@airflow.apache.org
> > For additional commands, e-mail: dev-help@airflow.apache.org
> >
> >
>
Re: [VOTE] AIP-94 Decouple Remote Commands from airflow CLI (to airflowctl)
Posted by Jarek Potiuk <ja...@potiuk.com>.
+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 <js...@apache.org> 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: dev-unsubscribe@airflow.apache.org
> For additional commands, e-mail: dev-help@airflow.apache.org
>
>
Re: [VOTE] AIP-94 Decouple Remote Commands from airflow CLI (to airflowctl)
Posted by Jens Scheffler <js...@apache.org>.
+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: dev-unsubscribe@airflow.apache.org
For additional commands, e-mail: dev-help@airflow.apache.org