Issue 121: update Postgres chart and identify as "dev"

[plumdog]

Fixes #121.

Thanks for submitting a PR! Please check the boxes below:

• I have filled in the "Changes" section below?
• I have filled in the "How did you test this code" section below?
• I have bumped the version number in /charts/flagsmith/Chart.yaml in the section version or I'm merging to a release branch

Changes

Update the bundled Postgres chart from chart version 8 in the old "stable" repos to chart version 12 in bitnami's repo.

No effort has been made to preserve data. All of the k8s resources will get replaced. Per the warning at https://docs.flagsmith.com/deployment/kubernetes#provided-database-configuration, recommend storing data in an external database

I reviewed the documentation at https://docs.bitnami.com/kubernetes/infrastructure/postgresql/administration/upgrade/ and determined that it would be silly to try to preserve data.

Further, have renamed to dev-postgres to make it very clear what this is for. There will be some documentation to update to accommodate this, but helm does handle our main use case: we want for users who have already set postgresql.enabled=false to still not have an in-cluster postgres after deploying this change, even though the name of the setting is now devPostgresql.enabled. Helm handles this for us, see https://v2.helm.sh/docs/developing_charts/#tags-and-condition-fields-in-requirements-yaml. So if postgresql.enabled is set to something, use that value. Otherwise use devPostgresql.enabled.

Below is the behaviour users will see based on the values they have set in their values:

postgresql.enabled	devPostgresql.enabled	PG before?	PG after?	Notes
[unset]	[unset]	yes	yes	✔️
true	[unset]	yes	yes	✔️
false	[unset]	no	no	✔️ (this is the important one)
[unset]	true	yes	yes	✔️
true	true	yes	yes	✔️
false	true	no	no	possibly slightly confusing, but inevitable as the values are asking for contradictory things
[unset]	false	yes	no	is a change in behaviour, but only a problem if a user has already set devPostgresql.enabled=false prior to upgrading for some reason, but not set postgresql.enabled=false and does want in-cluster Postgres. So this is actually what we want.
true	false	yes	yes	possibly slightly confusing, but inevitable as the values are asking for contradictory things
false	false	no	no	✔️

(PG before: "use the value in the first column if set, otherwise be yes"; PG after: "use the value in the first column if set, otherwise use the value in the second column, otherwise be yes")

So I think this behaves correctly, and the only possible surprises are where postgresql.enabled and devPostgresql.enabled are explicitly contradictory.

How did you test this code?

Deployed to minikube and check the upgrade was clean. Checked that postgresql.enabled/devPostgresql.enabled behaved as expected.

[plumdog]

@matthewelwell this is rebased and passing CI.

[matthewelwell]

@plumdog just reading the description, I think one of the sections is unfinished?

I reviewed the documentation at https://docs.bitnami.com/kubernetes/infrastructure/postgresql/administration/upgrade/ and determined that it

[plumdog]

@matthewelwell fixed.

[matthewelwell]

The next question is how we handle the release notes for this - given that there is a breaking change it's going to be critically important. As far as I can tell, we don't currently have release notes anywhere. Do we think it would be sufficient to add these to docs.flagsmith.com or perhaps we should just be adding them to the releases here: https://github.com/Flagsmith/flagsmith-charts/releases

Where would you expect to consume them @plumdog ?

[plumdog]

To use the Postgres chart as a guide, they have a note about upgrading in the chart readme (see https://artifacthub.io/packages/helm/bitnami/postgresql#upgrading which is also https://github.com/bitnami/charts/tree/main/bitnami/postgresql#upgrading) which links to their docs site (and the Postgres docs too)

That said, I guess the main thing is to decided a place where release notes go, and link to it from lots of places, but ultimately you can't intercept someone who applies an upgrade from 1.x to 2.x without reviewing a diff or looking for release notes, only make it very likely that someone who looks for release notes will find them.

So how about:

• section in https://docs.flagsmith.com/deployment/hosting/kubernetes about major version upgrades of the helm chart
• link explicitly to that from the chart readme (so will also appear on https://artifacthub.io/packages/helm/flagsmith/flagsmith)
• I think you can pin issues in GitHub so they are made more visible in the repo, which might be worthwhile

More knotty would be any outbound communication to users, many of whom won't be known if they're just using the open source version. And anyway, there's probably very little overlap between customers you know about and customers using the bundled in-cluster Postgres.

[plumdog]

@matthewelwell see Flagsmith/flagsmith#2357 for the docs, and have added a link to where those docs will end up to the chart's readme.

[plumdog]

@matthewelwell this is now rebased and passing CI, so I think is reviewable.

I also notice that the link from the docs repo will need updating to reference whatever chart version this ends up becoming.