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
