Downgrade postgresql-ha to 11.9.4 #541

2023-10-14T12:19:34Z

pat-s commented

2023-10-14 12:19:34 +00:00

(Migrated from gitea.com)

As 11.9.8 included (by mistake) a major version bump from 15 -> 16

https://github.com/bitnami/charts/issues/19596

As 11.9.8 included (by mistake) a major version bump from 15 -> 16 https://github.com/bitnami/charts/issues/19596

justusbunsi (Migrated from gitea.com) reviewed 2023-10-14 12:19:45 +00:00

justusbunsi (Migrated from gitea.com) reviewed 2023-10-14 14:33:31 +00:00

justusbunsi (Migrated from gitea.com) left a comment

The failing build is due to Chart.lock not properly recreated. You'd need to either only change Chart.yaml and then locally run helm dependency update, or change both Chart.yaml and Chart.lock and then run helm dependency update. 🙂

Anyway, Helm Chart 11.9.7 was never released. There was a build error for publishing¹. We need to downgrade to 11.9.4 as highest available version below 11.9.8².

The failing build is due to `Chart.lock` not properly recreated. You'd need to either only change `Chart.yaml` and then locally run `helm dependency update`, or change both `Chart.yaml` and `Chart.lock` and then run `helm dependency update`. 🙂 Anyway, Helm Chart 11.9.7 was never released. There was a build error for publishing[^1]. We need to downgrade to 11.9.4 as highest available version below 11.9.8[^2]. [^1]: https://github.com/bitnami/charts/actions/runs/6301595212/job/17106973762 [^2]: https://hub.docker.com/r/bitnamicharts/postgresql-ha/tags?page=1&name=11.9.

pat-s commented

2023-10-14 14:50:09 +00:00

(Migrated from gitea.com)

Anyway, Helm Chart 11.9.7 was never released. There was a build error for publishing1. We need to downgrade to 11.9.4 as highest available version below 11.9.82.

Ai. Yeah I didn't check and just assumed there was a 11.9.7.

Arguably they should have deleted 11.9.8 instead of keeping it.

The issue in the first place and then not deleting 11.9.8 is actually making me a bit worried WRT to the realibility of the bitnami charts. But well, let's move on and hope it doesn't occur again.

> Anyway, Helm Chart 11.9.7 was never released. There was a build error for publishing1. We need to downgrade to 11.9.4 as highest available version below 11.9.82. Ai. Yeah I didn't check and just assumed there was a 11.9.7. Arguably they should have deleted 11.9.8 instead of keeping it. The issue in the first place and then not deleting 11.9.8 is actually making me a bit worried WRT to the realibility of the bitnami charts. But well, let's move on and hope it doesn't occur again.

justusbunsi commented

2023-10-14 14:54:38 +00:00

(Migrated from gitea.com)

The issue in the first place and then not deleting 11.9.8 is actually making me a bit worried WRT to the realibility of the bitnami charts. But well, let's move on and hope it doesn't occur again.

We still could add tests checking the major version of our dependencies in the templating result. Since we have automerge enabled for minor updates, these tests would then pass. For major updates they would fail but there should be a review and test anyway. What do you think?

> The issue in the first place and then not deleting 11.9.8 is actually making me a bit worried WRT to the realibility of the bitnami charts. But well, let's move on and hope it doesn't occur again. We still could add tests checking the major version of our dependencies in the templating result. Since we have automerge enabled for minor updates, these tests would then pass. For major updates they would fail but there should be a review and test anyway. What do you think?

pat-s commented

2023-10-14 15:18:08 +00:00

(Migrated from gitea.com)

Interesting thought. You mean by comparing appVersion of the dep against a value defined in our templates?

This could help, yes - but then again another point to not forget when doing a major version bump. But the tests will remind us anyhow.

I wonder how we want to deal with major bumps of postgres and redis in the first place. We certainly want to upgrade but not necessarily right after they got released. Upgrading PG also takes manual work for all users which is not necessarily required when running a "reasonably" new PG version. We shouldn't fall too much behind but we also don't need to upgrade to every x.0 version just right after release. But this might be a separate discussion...

Interesting thought. You mean by comparing `appVersion` of the dep against a value defined in our templates? This could help, yes - but then again another point to not forget when doing a major version bump. But the tests will remind us anyhow. I wonder how we want to deal with major bumps of postgres and redis in the first place. We certainly want to upgrade but not necessarily right after they got released. Upgrading PG also takes manual work for all users which is not necessarily required when running a "reasonably" new PG version. We shouldn't fall too much behind but we also don't need to upgrade to every x.0 version just right after release. But this might be a separate discussion...

justusbunsi commented

2023-10-14 16:24:10 +00:00

(Migrated from gitea.com)

Interesting thought. You mean by comparing appVersion of the dep against a value defined in our templates?

Yes. We could check label app.kubernetes.io/version that contains the appVersion of the subchart. Unfortunately, ´postgresql-ha` in version 11.9.4 doesn't have that yet. It got added in 11.9.7 - which was not released. 😆
To check this, we would have to accept the major db upgrade. Which is not the idea of this PR. I've added this idea to #409.

I wonder how we want to deal with major bumps of postgres and redis in the first place. We certainly want to upgrade but not necessarily right after they got released. Upgrading PG also takes manual work for all users which is not necessarily required when running a "reasonably" new PG version. We shouldn't fall too much behind but we also don't need to upgrade to every x.0 version just right after release. But this might be a separate discussion...

I agree with all of that. And yes, that's another discussion.

> Interesting thought. You mean by comparing `appVersion` of the dep against a value defined in our templates? Yes. We could check label `app.kubernetes.io/version` that contains the appVersion of the subchart. Unfortunately, ´postgresql-ha` in version 11.9.4 doesn't have that yet. It got added in 11.9.7 - which was not released. 😆 To check this, we would have to accept the major db upgrade. Which is not the idea of this PR. I've added this idea to #409. > I wonder how we want to deal with major bumps of postgres and redis in the first place. We certainly want to upgrade but not necessarily right after they got released. Upgrading PG also takes manual work for all users which is not necessarily required when running a "reasonably" new PG version. We shouldn't fall too much behind but we also don't need to upgrade to every x.0 version just right after release. But this might be a separate discussion... I agree with all of that. And yes, that's another discussion.

justusbunsi (Migrated from gitea.com) approved these changes 2023-10-14 16:30:00 +00:00

justusbunsi (Migrated from gitea.com) left a comment

I've already tested this version along with my pgpool changes. LGTM.

Merging now. The appVersion related discussion can continue elsewhere.

I've already tested this version along with my `pgpool` changes. LGTM. Merging now. The appVersion related discussion can continue elsewhere.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: lunny/helm-chart#541