To expand on the "so I think we need to do one of":

- we need to update the name of "conn_id" somehow. I can't think of a
better option, and given all the operators have "x_conn_id" I don't
think that change should be made lightly.

- make conn_id unique (this "poor" HA has been a source of confusion in
the past) and the ID we use in the API

Or a third option:

- Have the API take conn_id and either return all conns for that
conn_id, or conn_id plus an ordinal (?idx=0 type thing) to return a
single value.

On Apr 8 2020, at 5:42 pm, Ash Berlin-Taylor <[email protected]> wrote:

> Hi everyone,
>  
> So as I mentioned in the AIP voting thread, I think we need to give
> some more thought to how we are exposing connection ids in the API.
>  
> Right now as proposed (and merged without approval, not cool. The AIP
> we voted on did not contain a PR against apache/airflow.) it has an
> end point of `/connections/{connection_id} ` 
>  
> My issue here is as I said in the previous thread: that is going to be
> mightly confusing to our users because there is a "conn_id" concept
> that is exposed, so people are going to try putting "aws_default" etc
> in there. I don't care what the API spec says, I care what our users
> expect, and having a connection_id/id and a conn_id fields is just confusing
>  
> So I think we need to do one of:
> - we need to update the name of "conn_id" somehow, make conn_id unique
> (this "poor" HA has been a source of confusion in the past)
>  
> There are similar problems for the DAG run -- the spec has the type as
> an integer, but everything else about the Airflow system uses the
> (unique) run_id parameter, and I would expect the API to use that. The
> autoinc. id on the run column is literally never used in the code
> base, so exposing that via the API seems odd.
>  
> A few other smaller points:
>  
> EventLog: Those are "audit"/action logs, so we probably shouldn't let
> people delete them via the API!
>  
> pool_id: still an integer. It should be the "name".
>  
> How should add/delete variables and connections work in the API  with
> the addition of the new "Secrets Backends"?
>  
> xcomValues: task_id is listed as an integer.
>  
>  
> -ash

Reply via email to