bugraoz93 commented on PR #45300: URL: https://github.com/apache/airflow/pull/45300#issuecomment-2726747281
> So, after sleeping on this idea, I want to pitch it... > > Have you considered having this new api-driven cli be completely standalone and in its own package from day 1? This would leave the existing db-backed cli as-is and functional. The vast majority of this PR is still usable, it'd just not be in `airflow` and not whack the old command. > > I'm imagining the scenario where I'm trying to troubleshoot in a remote deployment, jump into the scheduler pod, and try to run `airflow config get-value x y`. Having to auth not on my machine, where other people could also have access and grab my token, then clean up when I'm done isn't ideal. Effectively it'd have to do my troubleshooting remotely, which could be bit a bit cumbersome. > > Basically, this new api-driven command could be more like kubectl, airflowctl. Thanks for your comment @jedcunningham! Yes, this was designed [in the AIP-81](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=315493347#AIP81EnhancedSecurityinCLIviaIntegrationofAPI-ReleaseStrategy). In the first stage of design, my idea was directly like kubectl to airflowctl. In the comments, there were shouts at kubectl too. Of course, the name still will be `airflow` because of decisions at that time (in the dev calls) even though `airflowctl` was on the table in the AIP comments. The idea is indeed to have this as a separate package for sure. We can think of all `remote commands` that will be in the new CLI package. This will for example another thing we should add before separating into another package #47538. I agree with your point and security considerations. The `remote commands` will only work from remote machines because `airflow auth login` won't work in the scheduler or any components due to there being no installed `keyring` backend inside the containers. Of course, you can install a backend in a remote deployment scheduler pod and run it there but that would be similar if you install the separate CLI package for `remote commands` and use the `airflow auth login` in a similar fashion. I am not sure if we can easily prevent that from day 1 by making the new API-driven CLI be completely standalone package since it will still depend on how authentication is working with the `remote commands`. What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
