Postgresql container swapped for bitnami/postgresql suddenly in stable/postgresql

[arianitu]

So I just went to look at stable/postgresql and it suddenly switched from the official container to the bitnami container in this PR:

#8004

I was checking out the template vars and noticed replication was added, how great! Oh wait, it was added via a non standard container and would break everything I have running in production if I upgraded

I'm a little bit puzzled how you can suddenly pick an entirely different underlying container that doesn't work with any of the past charts and claim the chart postgresql is a stable chart.

I've definitely lost hope in running Helm in production. Please stick to standard containers and if you're going to use alternative containers, call them stable/bitnami-postgresql and don't just switch stable/postgresql to something completely different.

I do not want to run bitnami containers in production.

[arianitu]

I've made my own StatefulSet with the standard Postgres image in a master-replica setup in ~4 hours. Now I'm really confused why bitnami was used.

I'll clean it up and make it public, hopefully we can migrate this chart away from bitnami and back to the official Postgres image.

[carrodher]

I'm sorry that the recent changes to the postgresql community chart have been an issue for you, sadly we don't have a great way of signaling breaking changes in charts. I do agree that we could have avoided some of the unnecessary changes (like postgresqlPassword), but the use of the Bitnami image enables automation with the bitnami-bot, so we can ensure the image is up-to-date and secure.
Is there a specific reason you need to use library/postgres instead of bitnami/postgresql? We'd be happy to add what's missing from Docker Inc's image to make the transition easier.

The current problem here is that a lot of charts (including postgresql) are orphaned. All of the other Bitnami charts in the stable repo were initially contributed by Bitnami, before there was a separate Bitnami repo. Postgresql is the only chart Bitnami took over maintenance of. This means that previously the postgresql chart was not being updated so it would always remain in an old version unless someone was responsible for updating it (nobody did), in this case, users can always return to the previous version using that fixed version of the chart prior to the migration.

Going forward the community charts repository is being deprecated in favor of a distributed model where the community maintains charts across multiple repositories, discoverable via https://hub.helm.sh/. I think we can all agree that charts shouldn't be maintained by a single vendor (although the "official" docker images are not official at all but maintained by Docker employees), and users should have options from multiple sources, something that the distributed model will provide for https://github.com/helm/community/blob/master/proposals/distributed-search.md.
The fact that you can only have one "stable/postgresql" definitely discourages contributions and unintentionally grants a chart more meaning than others. In a more distributed/decentralized model, this is no longer an issue and it's up to the user to pick the most relevant chart for their needs

[Remigius2011]

@carrodher in order not to repeat myself, see my comments here: #8004

additional remarks:

I'm sorry that the recent changes to the postgresql community chart have been an issue for you, sadly we don't have a great way of signaling breaking changes in charts.

every chart has a README.md, wherein could be written e.g.:

TL;DR;

important notice: users of sersions of this chart prior to v. [put the last compatible version number here] should read the separate upgrade instructions below due to breaking changes introduced by v. [put the last incompatible version number here]

$ helm install stable/postgresql

(and add a section with upgrade instructions)

instead of:

TL;DR;

$ helm install stable/postgresql

orphaned charts: imho it is not a problem that the chart is orphaned as long as there is no immediate reason to update it (e.g. breaking changes in helm/k8s). if there is no possibility to file prs, this is a problem of the process of maintaining the charts, but not of a single chart.

"official" imges: maybe the term "official" for docker images is a bit unlucky, but the role of these images is clearly documented here: https://docs.docker.com/docker-hub/official_images/ and being provided by the manufacturer of the container runtime and provider of the repository they are made available on, the term is imho not completely unjustified. having a company backing some artifacts is not something bad per se (be it docker or bitnami, images / charts / whatever) - this may ensure coherence and sustainability if done properly.

accommodation of the official docker postgresql image: i am not fully aware of the difference between the official and the bitnami line of images, but i assume they are finite. environment variables could be duplicated / created with a configurable prefix or similar, paths could also be made configurable, if absolutely necessary, a general parameter could switch between presets for official and bitnami image. even if it defaults to the bitnami image, it would at least enable the use of the official image and provide an upgrade path (hopefully with some documentation) for users of the official images (and images derived from it).

"distributed model": whether the so-called "distributed model" improves the situation will be seen when it happens - hopefully it will!

[arianitu]

Here is what I am using in production now: https://github.com/arianitu/postgres-statefulset

Is there a specific reason you need to use library/postgres instead of bitnami/postgresql? We'd be happy to add what's missing from Docker Inc's image to make the transition easier.

Yes, I was using the Postgres image to create my own image that included PostGIS. I needed to be able to continue using my own images since that's what I based them off.

Also, what really sucks with all of this is that people using the old image can't just upgrade and get replication. It would have been awesome if you guys stuck with the official image and let everyone get replication.

[neerolyte]

sadly we don't have a great way of signaling breaking changes in charts.

Maybe a dumb question as someone new to this, but isn't that what the chart version following semver is for?

[desaintmartin]

Yes, it is, and it has been advertised as major version bump (i.e breaking) and with a paragraph about how to upgrade in the readme.
Maybe we should make sure that everybody understand that major version change means breaking things.

Of course this does not solve the main discussion issue.

[Remigius2011]

Of course this does not solve the main discussion issue.

agree.

[nicokaiser]

Some thoughts on official images vs. Bitnami images in general:

Having a company like Bitnami maintain Docker base images for official Helm charts is perfectly fine in my opinion. The bitnami-docker-* images seem well maintained and are definitely "production grade", and even minideb seems to be a good base image.

However, depending on specific servers in the images is what bothers me a bit. I like the idea of being able to re-create those images, using only official sources (Debian base image or their servers for debootstrap, maybe postgresql.org) in case the maintainer deletes them from the repositories. Bitnami images use some kind of "magic" in their Stacksmith packages installed with "bitnami-pkg" (from downloads.bitnami.com). There is no open documentation of how these files are being generated (or is there?), and how I could replicate this in case Bitnami stops maintaining one of these...

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Any further update will cause the issue/pull request to no longer be considered stale. Thank you for your contributions.

[stale]

This issue is being automatically closed due to inactivity.

[Remigius2011]

so it looks like bitnami has no interest in supporting business continuity of postgresql users. sad...

[desaintmartin]

To be honest, this has been discussed for 2 months before being implemented whereas the postgres helm chart was without maintainers for weeks.

I know this is not a proper solution, and yes we had to do the transition to bitnami-based image as well in my company, but at least it is alive.

Maybe the change was a mistake. Maybe not. I strongly encourage you to create your own postgres helm chart based on the last commit using the official image. This is not a joke: as the decentralization of this repository will be happening in a few months, it is good to have both "postgres chart with bitnami-based image" and "postgres chart with docker-backed based image".