+1 from my side. Like the idea and also this does not people lead to
think they can deploy via helm chart and run productive postgres.
On 27.07.25 13:51, Aritra Basu wrote:
+1 to everything, I think this is a good change to make. I think we should
preemptively go ahead with dropping it before we actually see breakage
--
Regards,
Aritra Basu
On Sun, 27 Jul 2025, 5:00 pm Jarek Potiuk, <ja...@potiuk.com> wrote:
Hello here,
We should decide what we should do with the bitnami Postgres chart we
include in our Helm Chart.
Few days ago Bitnami (now owned by Broadcom/ BMC) announced that they are
essentially stopping updating the open-source charts, moving them to
"legacy" repositories and "freezing" them essentially. You will have to
buy a subscription from them to get access to "security hardened" versions
of the images.
You can read the announcement here: https://github.com/bitnami/charts - I
also copy the current announcement text below. Also more information here
https://github.com/bitnami/containers/issues/83267
If I read the announcement correctly - our past released images will stop
working at some point in time when the embedded Postgres is enabled -
because the repository URL from which the postgres chart is pulled will
change (and freeze)
That message should be as a stark reminder that we should not publish and
release anything for the use of our users that essentially relies on
3rd-party commercial "free" offering, that might become "non-free" one day.
In this case - I think - we are pretty well covered, Postgres image was
only supposed to be used for development and testing purposes and nothing
else.
My proposal is that - in spite of Sqlite being already a "development"
database AND the changes Ash made to make it works with LocalExecutor and
better concurrency - is to completely remove Postgres from our chart and
make it use Sqlite. People should still be able to configure external
databases (Postgres/MySQL), but our tests in CI would use sqlite and
default installation would use SQLite as well. Also if they want to use
bitnami chart on their own - they would be able to have their own charts -
extending ours - and adding their own bitnami or other charts they would
want to use.
This approach has the nice property that there are some people who actually
use the embedded postgres - despite clear that they should not (because it
lacks production hardening, backups, management etc.). If we change it to
Sqlite - this will be far more obvious and make people think more about
using a "proper" database.
WDYT?
J.
-----
Announcement from Bitnami:
-------
Beginning August 28th, 2025, Bitnami will evolve its public catalog to
offer a curated set of hardened, security-focused images under the new
Bitnami Secure Images initiative. As part of this transition:
Granting community users access for the first time to security-optimized
versions of popular container images.
Bitnami will begin deprecating support for non-hardened, Debian-based
software images in its free tier and will gradually remove non-latest tags
from the public catalog. As a result, community users will have access to a
reduced number of hardened images. These images are published only under
the “latest” tag and are intended for development purposes
Starting August 28th, over two weeks, all existing container images,
including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated
from the public catalog (docker.io/bitnami) to the “Bitnami Legacy”
repository (docker.io/bitnamilegacy), where they will no longer receive
updates.
For production workloads and long-term support, users are encouraged to
adopt Bitnami Secure Images, which include hardened containers, smaller
attack surfaces, CVE transparency (via VEX/KEV), SBOMs, and enterprise
support.
These changes aim to improve the security posture of all Bitnami users by
promoting best practices for software supply chain integrity and up-to-date
deployments. For more details, visit the Bitnami Secure Images
announcement.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org
