potiuk opened a new pull request #22304: URL: https://github.com/apache/airflow/pull/22304
Despite our warnings, our users continue treating the Docker Compose that we exposed as something that should be easy to extend and customize for their own needs, yet they continue to struggle with some basic behaviour of containers, Docker Compose and how they interact. This results in vast space of potential problems as Docker Compose gives the user a false premise of something that "just works" where it requires quite a deep understanding on how it works. When you get things wrong with Docker Compose, you often end up with extremely confusing messages, that might suggest that the problem is with Airflow, but really the problem is with how users interact with their custom Docker images, registries, pulling, networking, mounting volumes and plenty other things. While this is the same with Kubernetes and Helm Chart, Helm Chart makes it infinitely easier to customize in declarative way (this is what our values.yaml does) and anything that has not been foreseen by Helm Chart developers is "hard" by definition. Docker Compose makes no such distinction. You really can't make Docker Compose customizable by configuration, and any customization in it requires modifying the compose file and for people who do not know what they are doing will eventually lead to errors that they are not able to diagnose and leads to creation of "Airlfow isssues", where they should be brought to "Docker Compose" issues. Example of that is here: https://github.com/apache/airflow/discussions/22301 where there are at least two issues that are not reproducible without knowing in detail what the user has done, how the image was build and distributed, and how the docker-compose installation interacted with them. This leads to a terrible distraction for supporting users of Airflow as the issues are really Docker Compose issues and Airflow maintainers should not be involved in solving those. This PR adds a bit stronger language and statement about the scope and customizability of the Quick Start Docker Compose of ours. Not only mentioning "Lack of Production Readiness" but also the responsibility of the user to understand and diagnose docker compose errors on their own and setting expectations that issues with Docker Compose running should be directed elsewhere. <!-- Thank you for contributing! Please make sure that your code changes are covered with tests. And in case of new features or big changes remember to adjust the documentation. Feel free to ping committers for the review! In case of existing issue, reference it using one of the following: closes: #ISSUE related: #ISSUE How to write a good git commit message: http://chris.beams.io/posts/git-commit/ --> --- **^ Add meaningful description above** Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#pull-request-guidelines)** for more information. In case of fundamental code change, Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvements+Proposals)) is needed. In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). In case of backwards incompatible changes please leave a note in [UPDATING.md](https://github.com/apache/airflow/blob/main/UPDATING.md). -- 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]
