Thanks, Vikram! Answered them in the proposal. --- Thanks, Jarek! It's a pleasure to be part of and work on this one! :)
Thanks for the points! - Indeed, secure-by-design should be one of the ground pillars of the CLI. I included a small part in the proposal. I will make it more detailed soon. - Agree, releasing this as a separate package would make it easier to maintain releases and help reduce dependencies. I liked the name apache-airflow-cli. I included it in the proposal so everyone can start thinking about the name if they have any other suggestions. - I have the same sense of auto-generating as much as possible. While writing the naming convention part, the whole idea was to generate a set of commands from API via a certain naming convention. Idea indeed should be auto-generated as much as possible without relying on too many changes per new/updated API endpoint but relying on certain configuration files such as OpenAPI description (or possible chosen API technology)). - Yes, indeed there are some commands like you mentioned. Additionally, some executor-specific commands fall into “Hybrid” commands as well. Great idea! I agree with making an inventory. The idea behind proposing a categorisation between commands was to know what we have and categorise them. The categorization will help us in multiple steps of this AIP. So, indeed one part of the proposal should include an inventory and a mapping. I will create the inventory. I will map them with the current API endpoints soon. I will include the inventory and mapping in the AIP when ready. Kind regards! On Fri, Jul 26, 2024 at 10:31 AM Jarek Potiuk <ja...@potiuk.com> wrote: > Thanks - that looks cool and great you want to take it on :). > > I think the point you made Vikram is very important and worth mentioning > here on the devlist. One of the "common" part of AIP-72, AIP-78, AIP-82 but > also the parallel stream of security review of our dependencies, will be > connected to the API technology we are going to use - because Ideally, we > should come up with single, coherent API mechanism used across all our > components. > > I do not want to make a tangential discussion here - so this likely > warrants a separate discussion (Kaxil - maybe we can add it for the next > DEV call)? > > Also I have few other concrete points to add that would be great to include > in the proposal: > > - the CLI should be secure-by-design (for example any secrets passed to > it could be passed via env vars or "reading" from stdin) > - I believe the CLI should be a separate package - that should not have > to have all the same dependencies as "airflow" has - way less number of > those should be needed to run the "apache-airlfow-cli" package (proposed > name) > - Ideally the API CLI should be as much generated as possible - possibly > there are tools that can help with that or we can improve / rewrite the > CLI > framework to generate CLI in big parts from (possibly?) OpenAPI > description > (most likely - it also depends on possible API technology choices of > ours). > - Currently our CLI is pluggable and has various types of command - > commands can be contributed by providers - this should be something to > consider as well - they likely fall into "Hybrid" commands - but I > think > it would be a great idea to make an inventory of current command and > make > them part of the proposal to classify the commands. > > J > > On Fri, Jul 26, 2024 at 1:20 AM Vikram Koka <vik...@astronomer.io.invalid> > wrote: > > > Thanks for writing this up! > > > > I left a quick question as a comment in the proposal. > > > > Best regards, > > Vikram > > > > > > On Wed, Jul 24, 2024 at 2:15 PM Buğra Öztürk <ozturkbugr...@gmail.com> > > wrote: > > > > > Hey all, > > > I have created a proposal for an Airflow 3.0 workstream: to utilize API > > for > > > CLI > > > > > > Details in https://cwiki.apache.org/confluence/x/4wvOEg > > > > > > I tried to make it simple and less detailed until we agreed on the > > > approach. > > > Please provide any feedback. This is my first AIP so any feedback will > be > > > valuable. > > > > > > Kind regards, > > > -- > > > Bugra Ozturk > > > Data Engineer > > > > > > -- Bugra Ozturk
