potiuk commented on a change in pull request #16170: URL: https://github.com/apache/airflow/pull/16170#discussion_r642917919
########## File path: docs/helm-chart/quick-start.rst ########## @@ -65,8 +65,17 @@ Run ``kubectl port-forward svc/airflow-webserver 8080:8080 -n airflow`` to port-forward the Airflow UI to http://localhost:8080/ to confirm Airflow is working. -Build a Docker image from your DAGs ------------------------------------ +Extending Airflow Image Review comment: I think this falls into a "quick start" actually. Originally there was only "adding DAGs to your image" here. but I think it will be as common to add PyPI/Apt dependencies during the "quick start". If you add your DAGs, very likely you want to add dependency. This was the top ask from Helm chart users - in slack in elsewhere ("How can I add new dependency"). I think many users do not realize how easy it is for your local environment to build and deploy your image (and that is needed sooner-or-later most of the time anyway for Airflow). I think this was the main reason why @MarkusTeufelberger and others used the "additional Packages" option in the original helm chart - they did not realize (or did not want to make the extra hoop) that they can easily (and should) add PyPI/APT packages via custom image. I think this is the original fallacy of the "dynamic" installation method. You are tempted to do everything by helm chart configuration. Unfortunately (or fortunately depends how you look at it) Kubernetes + Helm + Docker(Container) images are all a leaky-abstraction. You should understand (at least to some extent) all of it and be able to modify all of it when you want to deploy application via the helm chart. So the docs has to be a little about all of it. By adding it where they will be looking for a "quick start" it's also a bit of educating the users that they can and should do it. Also The "quick start" here is not a "generic" quick start. This is "Quick Start with kind" - very specific case, where you use `kind` as test-and-try platform (you should not use `kind` in production - it is intended for test and development). Building and loading images in kind is just natural part of the flow with kind. And for the "quick start", you should find all the "quick need" answers on that single page rather than somewhere else (even if you could have a link). So I think adding the most common "quick-start" scenarios makes perfect sense, even if it involves building the image and not configuring helm chart. I thought a bit about this and I am 100% sure this is best place for it. For production deployment - yes, there is no need to describe it there, simply reference to "Building the image" is enough as for production deployment you have more experience and time to read it. Also GitLab is a bit different story. GitLab works standalone out-of-the-box for vast majority of cases. There are very little reasons you would like to build GitLab image. On the other hand - I cannot imagine a "serious" deployment of Airflow where you would use the "reference" image. You need to learn to build your own Airflow image - the sooner, the better. -- 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. For queries about this service, please contact Infrastructure at: [email protected]
