Hi everyone, I have finalized the categorization, mapping, and authentication sections. Could you please review the AIP when you have a moment? Your feedback would be greatly appreciated and valuable. After this round of reviews, I think we can start voting for the AIP. Thanks!
Kind regards, Bugra On Fri, Aug 2, 2024 at 7:45 PM Buğra Öztürk <ozturkbugr...@gmail.com> wrote: > It's fun for me to make Airflow better. I have responded to them and > adjusted the document accordingly. Thanks a lot, Kaxil! > > On Fri, Aug 2, 2024 at 3:06 AM Kaxil Naik <kaxiln...@gmail.com> wrote: > >> Thanks, Bugra, great turnaround on such a short notice. I have added my >> comments too. >> >> Regards, >> Kaxil >> >> On Sat, 27 Jul 2024 at 17:08, Buğra Öztürk <ozturkbugr...@gmail.com> >> wrote: >> >> > 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 >> > >> > > > -- > Bugra Ozturk > -- Bugra Ozturk
