[WIP] chore(deps): bump bitnami-common and bitnami-postgresql versions

[coreydaley]

Description of the change

The bitnami-common and bitnami-postgresql dependencies are pretty old and could use an update to provide expanded functionality for the Backstage Helm Chart. This update bumps both packages to their current latest versions

Existing or Associated Issue(s)

Fixes #191

Additional Information

Checklist

• Chart version bumped in Chart.yaml according to semver.
• Variables are documented in the values.yaml and added to the README.md. The helm-docs utility can be used to generate the necessary content. Use helm-docs --dry-run to preview the content.
• JSON Schema generated.
• List tests pass for Chart using the Chart Testing tool and the ct lint command.

[ChrisJBurns]

Thanks @coreydaley, beat me to it (although I was taking a while), for reference, this was the issue raised to bump the deps #191.

Although I think we'll need a major version update to the Backstage Helm Chart as we are updating the Postgres Sub-Chart by 4 major versions. I'm wondering what we should do around testing? We don't want to cause problems for those who are on Postgres 12 (and haven't overridden the DB image chart values for it)

[coreydaley]

@ChrisJBurns no worries, I would like to get the ability to set the global.compatibility.openshift.adaptSecurityContext option which is in the newer versions.

[coreydaley]

@ChrisJBurns The base helm install is working on minikube, can you authorize the workflow that is awaiting approval?

[coreydaley]

@ChrisJBurns As far as the PostgreSQL getting upgraded, I think that documentation/release notes/education is the way to go, hopefully people will see that it is a major version bump and read the docs/notes. The upgrade from any major-to-major PostgreSQL version looks to be a manual process, probably using the pgupgrade command.

We could also do some manual testing and see if a helm rollback to the previous chart version would let a user recover from doing an upgrade and continue to work while they figure out why it failed, which will be because of the PostgreSQL difference. Thoughts?

An alternative (maybe) would be to update this chart to bake in the version of PostgreSQL that is currently supported and people can upgrade if they want to? Would definitely have to be some manual verification of if that would work, but it seems like it would. If they have overridden it to a different version that should still work, and if not, the version would still be what they had before.

[ChrisJBurns]

@coreydaley Will approve the PR just to kick off the workflow, we can have a think in the meantime of the best way of going about the upgrade is and communicating that to users.

[coreydaley]

@ChrisJBurns Do you think this would be an appropriate topic for me to bring up on the SIG Framework call?

[ChrisJBurns]

@coreydaley Which SIG Framework are you referring to? Having a think, I'm wondering if we want to implement the incremental major bumps instead of jump from 12 to 16? This somewhat gives users the opportunity to minimise the amount of changes to the underlying chart per release?

[coreydaley]

@ChrisJBurns Sorry, this one: https://github.com/backstage/community/tree/main/sigs/sig-framework

Let me do a bit of testing and see what kind of issues we can expect and I'll post back my results here (hopefully early this week)