Hi David, I assume that you then want to ensure that all calls from the CLI are being made through the Rest-API. In other words the json_client would be the only client remaining. The local_client is a security problem as it needs direct database access which makes it problematic to have normals user use the cli.
If this is the case then yes this would be great, but please note that airflow backfills are more difficult to factor out then. Cheers Bolke Verstuurd vanaf mijn iPad > Op 1 feb. 2019 om 03:26 heeft David Cavaletto <[email protected]> het > volgende geschreven: > > In case my images didn't come through, here is a link that shows what I'd > like to remove (in red) and add (in green) > > https://docs.google.com/drawings/d/1Ux8qGQUdRp2L6YWgqayliIzFiJv1nwev4JaG2rR7oiQ/edit?usp=sharing > > >> On Thu, Jan 31, 2019 at 8:21 PM David Cavaletto <[email protected]> >> wrote: >> Hello, >> >> While trying to refactor the Connection API (both REST and CLI) I've >> discovered the CLI has the ability to make REST API calls. The flow looks >> like this: >> >> >> In a discussion with Ash in Slack, he said this architecture is so that a >> user can use a local installation of Airflow (like on their laptop) to issue >> CLI commands to a remote installation of Airflow. Examples would include a >> cluster running Fargate, where docker exec and ssh are not available, and so >> no CLI commands can be run on the installation. >> >> I'd like to propose that we simplify this entire structure, removing the >> boxes highlighted in red, like this: >> >> >> Users needing to issue REST commands to a cluster would use a REST client >> (Postman, curl, etc) to issue the commands to the cluster, allowing us to >> simplify this implementation of the APIs in Airflow. >> >> Thoughts? Is there some other use case I've overlooked? >> >> -Dave
