potiuk commented on issue #19250: URL: https://github.com/apache/airflow/issues/19250#issuecomment-953084313
My first point is - cool way of doing it. But I think it does not fit in Airflow code. It requires dependency to Quarkus (as I understand it) and if we make it part of the helm chart (this is where it fits at very best as this is the only link we have with K8S deployment), it introduces a new "option" to use DAG syncing which I think moves us a bitt too close to be K8S-tied. It also lacks testing - all the code we have is heavily tested automatically - in all the variants and configurations. For one our Helm Chart is fully tested with unit and integration tests and any code incorporated to Airflow will have to be equally well tested.. Also look at our talk with @kaxil : https://airflowsummit.org/sessions/2021/airflow-loves-kubernetes/ - while Airflow Loves Kubernetes, K8S is only only of many deployment options for us. Using GitSync is a bit more "agnostic" and - unless there is a very good reason - why the CRD-way could better, I see no reason why it should be incorporated by the community.. Unless there are some good arguments, the fact that something is "cloud native", does not automatically means "it's better" - it's a bit misconception, and in Airflow's world, being "cloud native" bears the conotation of ("we can only target part of our users this way") - which oftem means it's not worth the effort, unless it REALLY brings some beneffits. I think it better fits the https://airflow.apache.org/ecosystem/ page to be honest - if someone wants to use it, they could (and it's as easy as adding a link to your Repo there via PR). @jedcunningham @kaxil @dimberman - WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
