Request: switch default track from `latest` to `14` for postgresql(-k8s) charms

charmhub requests
1

Hi,

Jon (on meeting with Mark) requested to switch default track for charms postgresql and postgresql-k8s from latest to 14 to avoid usage of the old charm in new installations.

Can you please perform the switch. Thank you!

2

Hi, I can do this, one thing though - would publishing the same revision for Postgres 14 in latest achieve the same result? It’s fine if a revision is published in two tracks/channels.

Let me know! If not, I can certainly designate 14 as the default track - Actually, I think I can set 14 as default anyway, what I described above might remove the need for closing latest. But let me know .

  • Daniel
3

We cannot publish Data-platform-charm-revision=288 into track latest as we do not provide in-place upgrade from legacy charm to our/new one (juju refresh will corrupt postgresql data on on already installed servers).

The latest track revision=290 is coming for IS team legacy charm. They cannot migrate on 14/stable until we provide extensions support.

So, IS team is still using (and publishing) their charm to the latest/stable, but Mark/Jon do not want to keep it default. They insist to use new data-platform charm by default (14/stable).

Technically we can close latest/stable today as:

  • juju deploy --channel latest/stable # will continue working
  • charmcraft upload postgresql --channel latest/stable --release # will continue working and will reopen the channel on each release, so we will have to close it again and again.

I hope it is still possible to switch defaults without closing latest/stable. cc: @mthaddon

4

Hi, this is done :slight_smile: Thanks for the explanation.

– Daniel

5

By the way, this bug (which you found - thanks!) will cause problems once you close latest. It’s what’s affecting the mysql charms as well. The Juju team helped us trace this to the charmhub side.

  • Daniel
1 Like
6

Thank you Daniel!

JFYI only, juju behaves differently for mysql-k8s and postgresql-k8s currently:

ubuntu@test-k8s:~$ juju deploy mysql-k8s
ERROR selecting releases: charm or bundle not found for channel "", platform "amd64"
available releases are:
  channel "edge": available series are: jammy
  channel "8.0/stable": available series are: jammy
  channel "8.0/candidate": available series are: jammy
  channel "8.0/beta": available series are: jammy
  channel "8.0/edge": available series are: jammy

ubuntu@test-k8s:~$ juju deploy postgresql-k8s
ERROR resolving retry error: No revision was found in the Store.

So, keeping latest/stable for postgresql-k8s doesn’t help a lot. :slight_smile:

7

So, keeping latest/stable for postgresql-k8s doesn’t help a lot.

Dear @roadmr , please check Mattermost , if possible, please rise the priority for this bugreport. Thank you!

8

@roadmr the bugreport is closed now, but the issue is still here.

Are some changes necessary on Juju side as well?

ubuntu@taurus-dev:~$ juju deploy postgresql
ERROR resolving retry error: No revision was found in the Store.
ubuntu@taurus-dev:~$ juju deploy postgresql-k8s
ERROR resolving retry error: No revision was found in the Store.
ubuntu@taurus-dev:~$ juju deploy mysql
ERROR selecting releases: charm or bundle not found for channel "", platform "amd64"
available releases are:
  channel "8.0/stable": available series are: jammy
  channel "8.0/candidate": available series are: jammy
  channel "8.0/beta": available series are: jammy
  channel "8.0/edge": available series are: jammy
ubuntu@taurus-dev:~$ juju deploy mysql-k8s
ERROR selecting releases: charm or bundle not found for channel "", platform "amd64"
available releases are:
  channel "edge": available series are: jammy
  channel "8.0/stable": available series are: jammy
  channel "8.0/candidate": available series are: jammy
  channel "8.0/beta": available series are: jammy
  channel "8.0/edge": available series are: jammy
ubuntu@taurus-dev:~$

Thx!

9

Hi Alex,

Could you tell us what version of Juju you’re running? I can’t reproduce on a VM running 2.9.42; both postgresql-k8s and mysql-k8s deploy fine (and I’m assuming the machine versions of both would also deploy correctly). Knowing the version you’re using could help us dig further into the problem.

Thanks for continuing to report your issues, and sorry they haven’t quite been solved yet!

10

I confirm, the issue is solved now. I cannot reproduce it anymore. P.S. it was pre-2.9.43 from 2.9/edge. Anyway tested on 2.9.42 and the same pre-2.9.43, all OK now. THANK YOU!