+1 on all written by Jed and Jens. Great proposal. On Thu, Dec 4, 2025 at 8:49 PM Jens Scheffler <[email protected]> wrote:
> +1 to all Jed said - and as I said during devcall. > > We can point to the Postgres operator as a good example and drop some > notes as an example how to make it running such that a low entry barrier > is there. But DB operations is complex, you need backups, disaster > recovery, HA, need to monitor and tune performance, many different > storage backends. Might all be good and Zalando might really have a good > job but still it is easily getting into a direction where it is expected > we drive also support. > > We might and should provide a minimal example that we also use for our > CI (can be the opertor or a simple 10-line YAML to deploy a simple > postgres container just for testing. But the easiest is like Jed also > mentioned during the call to just call the following CLI: > > |kubectl run postgres --image=postgres > --env="POSTGRES_PASSWORD=yourpassword"--port=5432| > > Fpr Kustomize I am also OK with the assumptions: > > * We provide a space where documented examples can land which can be > easily contributed by users such that people can easily "shop" for > additional features > * For all stuff we strip-out of the chart we should move an example as > replacement > > That also means - like Jarek referenced - we should reduce the PR to > remove postgres to really only remove postgres from the chart but not > adding sqlite. Sqlite is cool for `airflow standalone` but I am afraid > about the complexity adding this with shared storage to the chart. > > Jens > > On 12/4/25 17:12, Jed Cunningham wrote: > > Big +1 on significantly simplifying our chart and documenting how to use > > Kustomize. I've been shopping that idea around for a while now and have > > received nearly universal thumbs up on the idea. It's very similar to how > > we moved from exposing "everything in the pod" in Airflow config to the > > pod_template_file back in 1.10.something - same high level problem. I > think > > this is the right direction for the chart and it will help a lot to make > it > > more maintainable. > > > > However, I'm not sold on integrating the postgres operator and trying to > > offer a "production" db out of the box. There is just too much that goes > > into it. I'd be very happy to, however, document how it can be done and > > possibly even test that it works. But I do not think we should stand up > > that piece of the puzzle for people. Alternatively, what do you think > about > > having a very simple statefulset/service to stand up a "dev" db - we can > > even move the config to something like `devPostgres` or something and > leave > > it disabled by default. Then we maintain the ease of "single command to > > stand up", we can use it for the bulk of our tests, etc. Of course, folks > > could choose to kustomize away and use it, but no one could argue they > > thought it was a fully supported production level thing then and they are > > on their own. > >
