+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.
