New PostgreSQL charm is also a juju-interface compatible replacement for legacy PostgreSQL charms (using legacy interface “pgsql”, via endpoints “db” and “db-admin”).
However, it is highly recommended to migrate to the modern interface “postgresql_client” (endpoint “database”).
Please contact us, see details below, if you are considering migrating from other “legacy” charms not mentioned above. Additionally:
MySQL(-K8s) charms/SNAPs use the track “8.0”.
PostgreSQL(-K8s) charms/SNAPs use the track “14”.
No “latest” track in use (no surprises in tracking “latest/stable”)!
PostgreSQL(-K8s) charms provide legacy charm through “latest/stable”.
New PostgreSQL charm is also a juju-interface compatible replacement for legacy PostgreSQL charms (using legacy interface “pgsql”, via endpoints “db” and “db-admin”). However, it is highly recommended to migrate to the modern interface “postgresql_client ” (endpoint “database”).
So if I had been using an older postgresql charm on say bionic… with db and db-admin … do I just collapse both relations to database and call it a day?
I started using the new charm and ran into issues… now that i read this post I will try to switch interfaces.
I tried to offer database across models but… seems it didn’t work… I must be misunderstanding the migration instructions
- create offer postgresql using postgresql:database
ERROR cannot deploy bundle: cannot add application offer "postgresql": getting relation endpoint for relation "database" and application "postgresql": application "postgresql" has no "database" relation
Im on postgresql charm series jammy Revision#290 latest/stable channel
Let me highlight one important part: there are two types of code stored under the same charm name postgresql:
Reactive postgresql charm in the channel latest/stable (called legacy)
Operator-framework-based postgresql charm in the channel 14/stable (called modern)
The legacy charm provided endpoints db and db-admin (for the interface pgsql).
The modern charm provides old endpoints as well + new endpoint database (for the interface postgresql_client).
You can read more detail about the available endpoints/interfaces here.
Please choose one endpoint to use, there are no need to relate all of them simultaneously!
We are preparing the complete guide “How to migrate to the new charms”. In a couple of words:
quick try: relate you current application with new charm using endpoint db (set the channel to 14/stable in your bundle). No extra changes should be necessary:
Note: NO in-place upgrades! Reactive charm cannot be upgraded to Operator-framework-based one. To move your DB data, you have to launch the second DB application from channel 14/stable nearby and copy data from App-DB latest/stable to App-DB 14/stable! We are preparing copy&paste guide right now.
I hope it brings more light here. We are planning to add some FAQ to the charm documentation. Tnx!
Okay now that I’ve pinned the channel I can see the new interface … however I am trying to figure out how to open up connectivity for outside of the container connections…
- deploy application postgresql from charm-hub on jammy with 14/stable
ERROR cannot deploy bundle: cannot deploy application "postgresql": unknown option "extra_pg_auth"
I will remove this for now and continue testing… I think I had had that setting above when connecting directly to debug content but… that’s no longer necessary… looking forward to more docs on this sort of setting though.
We don’t think that “extra_pg_auth” option has a sense for new Data Platform charms.
On K8s Juju, Kubernetes itself has good network isolation on the namespace level.
On Machine Juju we recommend using Juju network spaces.