Re: [PROPOSAL][AIP-32] Airflow REST API

On 6 Mar 2020 3:30 pm, Kamil Breguła wrote: > I think it won't be a problem to modify this solution and store permission > information only in the code for the API. We will not use the permission view > table completely. Can you expand on how you propose we manage permissions? If we aren't usin

Re: [PROPOSAL][AIP-32] Airflow REST API

I think it’s totally reasonable to support multiple versions but offer a deprecation system. We can look at how kubernetes handles deprecation in its API for a template. via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.6&source=email_footer_2] On Fri, Mar 6, 2020 at

Re: [PROPOSAL][AIP-32] Airflow REST API

On Sun, Mar 1, 2020 at 7:23 PM Ash Berlin-Taylor wrote: > > On Mar 1 2020, at 5:11 pm, Jarek Potiuk wrote: > Do we need to support multiple versions of API concurrently, or can we put > any such requirement on the client(s)? And so long as we have good > updating/change log for the API versions

Re: [PROPOSAL][AIP-32] Airflow REST API

On Fri, Feb 28, 2020 at 5:01 PM Ash Berlin-Taylor wrote: > > To view the API spec > > in an easier to consume form I used https://editor.swagger.io/ and imported > from the (raw) github URL >

Re: [PROPOSAL][AIP-32] Airflow REST API

On Sat, Feb 29, 2020 at 2:02 AM Matt Buell wrote: > > Nice job Kamil, I really like where this is going - especially in regards > to Variable and XCOM functionality. > > With regards to the Task Instance and XCOM endpoints, I was wondering what > everyone's thoughts would be on using 'dag_run_id'

Re: [PROPOSAL][AIP-32] Airflow REST API

On Fri, Feb 28, 2020 at 4:15 PM Ash Berlin-Taylor wrote: > > Great work Kamil, I can't wait till we have a fully featured API in Airflow! > > So AIP-13 has been voted on and "accepted". Do you have a proposal for what > we should do with that AIP that we've already voted upon? I think we can mar

Re: [PROPOSAL][AIP-32] Airflow REST API

@Jarek your points have fully convinced me. I like the spec first approach On Sun, Mar 1, 2020 at 2:03 PM Vikram Koka wrote: > In response to the point raised by Jarek, i.e. 'API first' or 'Code first', > looking at the document, one of the stated goals is: > "The API will be intended for use

Re: [PROPOSAL][AIP-32] Airflow REST API

In response to the point raised by Jarek, i.e. 'API first' or 'Code first', looking at the document, one of the stated goals is: "The API will be intended for use by any third party. It should not be related to a specific application, e.g. a React UI" In my opinion, the 'Code first' approach on

Re: [PROPOSAL][AIP-32] Airflow REST API

On Mar 1 2020, at 5:11 pm, Jarek Potiuk wrote: > At this point you immediately lose all the flexibility that comes with "code > first" approach: you released the API already and you are not supposed to > change how the API is designed, yet the design is by-product of the code so > it is very di

Re: [PROPOSAL][AIP-32] Airflow REST API

I have not yet reviewed the API in detail - and I am sure there will be more things coming up while implementing it, but just one general comment (to Ash and Matt concerns). I think we need to agree on the "API first" vs. "Code First" approach (and possibly vote if we have disagreement after discu

Re: [PROPOSAL][AIP-32] Airflow REST API

Nice job Kamil, I really like where this is going - especially in regards to Variable and XCOM functionality. With regards to the Task Instance and XCOM endpoints, I was wondering what everyone's thoughts would be on using 'dag_run_id' as a unique identifier as opposed to the existing 'execution_d

Re: [PROPOSAL][AIP-32] Airflow REST API

An easier URL to view the spec https://editor.swagger.io/?url=https://raw.githubusercontent.com/PolideaInternal/airflow/1e3e444d03c2e08d8fcee274d9e745a3d3ddeca8/openapi.yaml On Feb 28 2020, at 4:01 pm, Ash Berlin-Taylor wrote: > To view the API spec >

Re: [PROPOSAL][AIP-32] Airflow REST API

To view the API spec in an easier to consume form I used https://editor.swagger.io/ and imported from the (raw) github URL Some comments on the proposed OpenAPI spec; connection id's are not

Re: [PROPOSAL][AIP-32] Airflow REST API

Great work Kamil, I can't wait till we have a fully featured API in Airflow! So AIP-13 has been voted on and "accepted". Do you have a proposal for what we should do with that AIP that we've already voted upon? In the permissions section you talk about creating, for example "can_edit_variable" -

[PROPOSAL][AIP-32] Airflow REST API

Hello, I just created "AIP-32 - Airflow REST API" proposal and would love community feedback and comments. https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+REST+API I would love to know what is your expectation from the API. We currently have one experimental API, but despite