Sorry to weigh in at the last minute, but I'm wary of gRPC over just
JSON, so -1 to that specific choice. Everything else I'm happy with.
I (or Andrew G) will follow up with more details shortly.
-ash
On Wed, Aug 10 2022 at 19:38:59 +02:00:00, Jarek Potiuk
<ja...@potiuk.com> wrote:
Oh yeah :)
On Wed, Aug 10, 2022 at 7:23 PM Ping Zhang <pin...@umich.edu
<mailto:pin...@umich.edu>> wrote:
ah, good call.
I guess the email template can be updated:
Only votes from PMC members are binding, but members of the
community are encouraged to check the AIP and vote with
"(non-binding)".
+1 (binding)
Thanks,
Ping
On Wed, Aug 10, 2022 at 10:20 AM Jarek Potiuk <ja...@potiuk.com
<mailto:ja...@potiuk.com>> wrote:
Thank you . And BTW. It's binding Ping :). For AIP's commiter's
votes are binding. See
<https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#commit-policy>
:D
On Wed, Aug 10, 2022 at 7:16 PM Ping Zhang <pin...@umich.edu
<mailto:pin...@umich.edu>> wrote:
+1 (non-binding)
Thanks,
Ping
On Thu, Aug 4, 2022 at 1:42 AM Jarek Potiuk <ja...@potiuk.com
<mailto:ja...@potiuk.com>> wrote:
Hey everyone,
I would like to cast a vote for "AIP-44 - Airflow Internal API".
The AIP-44 is here:
<https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-44+Airflow+Internal+API>
Discussion thread:
<https://lists.apache.org/thread/nsmo339m618kjzsdkwq83z8omrt08zh3>
The voting will last for 5 days (until 9th of August 2022 11:00
CEST), and until at least 3 binding votes have been cast.
Please vote accordingly:
[ ] + 1 approve
[ ] + 0 no opinion
[ ] - 1 disapprove with the reason
Only votes from PMC members are binding, but members of the
community are encouraged to check the AIP and vote with
"(non-binding)".
----
Just a summary of where we are:
It's been long in the making, but I think it might be a great
step-forward to our long-term multi-tenancy goal. I believe the
proposal I have is quite well thought out and discussed a lot in
the past:
* we have a working POC for implementation used for performance
testing: <https://github.com/apache/airflow/pull/25094>
* it is based on on industry-standard open-source gRPC (which is
already our dependency) which fits better the RPC "model" we need
than our public REST API.
* it has moderate performance impact and rather good
maintainability features (very little impact on regular
development effort)
* it is fully backwards compatible - the new DB isolation will be
an optional feature
* has a solid plan for full test coverage in our CI
* has a backing and plans for more extensive complete testing in
"real" environment with Google Composer team support
* allows for further extensions as part of AIP-1 (I am planning
to re-establish sig-multitenancy effort for follow up AIPs once
this one is well in progress).
J.
