[feature request] Changing name of models in Juju

erik-lonroth · 11 February 2025 09:28

The ability to change or set model names is a long sought for feature. It comes up regularly and I thought to cover this some here:

Juju does not currently support changing names of models (2025-February) version 3.6+

Why be able to change name of models?

Names on models is how we can organize ourselves when multiple users collaborate with juju services and their use. Its how we can communicate efficiently to find, organize and reason about our systems together in teams. Names matters alot there.

For example, one might name models after clients that are hosted, like: “client-system-foo”, “client-system-bar”. Then suddenly the client decided to change name. How would we communicate with team-members about this when a client name suddenly doesn’t mean the same thing any more? A redeploy is the only option, when a simple name change would have resolved it.

Another example is that you might have a domain name for a SaaS being used in the model name to help keep track of that this service is hosted from a particular model. Like “my-service-example-com”. If its then decided to “rebrand” the service into "another-service-example-com. Imagine the confusion when this name suddenly indicates something that isn’t there any more. A name change would have resolved it, but now a redeploy is needed again.

The ability to “rename” juju models would be a nice improvement to Juju going forward and help us be even more efficient in operating complex infrastructure.

What do you think?

ppasotti · 11 February 2025 12:33

I think this is impossible with the present implementation, because it would be unpractical with kubernetes models as they correspond to namespaces. IIRC there were talks of a future possibility to conceptually separate models and k8s namespaces. If and when, this could be opened up again?

@wallyworld perhaps can confirm or deny

mastier1 · 15 April 2026 16:40

@ppasotti @wallyworld looking forward also to your reply here

wallyworld · 16 April 2026 01:06

Yeah, there’s a few moving parts. We have a feature request jira board where things like this can be added. The prioritisation of these requests is done by the juju director and product manager.

https://warthogs.atlassian.net/jira/software/c/projects/PF/boards/440?quickFilter=3352

That’s the best I can give you right now - requests like this need to be considered along with everything else.

erik-lonroth · 23 April 2026 09:21

I would consider the “model_uuid” would be much more a stable reference and I guess that would be usable also for k8 namespaces?

Renaming models would allow one to be much more organized over time.

Our naming standards has drifted significantly over the years and we are now left with a mess in our controllers where multiple generations of model names exists and causes lots of confusion.

This feature would target the “operations” of infrastructure directly, which is what juju should be all about?

mastier1 · 7 May 2026 08:43

@wallyworld thank you. That was already reported by my colleague @ggouzi as internal ticket on this board 3 weeks ago. Not yet evaluated unfortunately. https://warthogs.atlassian.net/jira/software/c/projects/PF/boards/440?quickFilter=3352&search=model&selectedIssue=PF-6630

Actually recently we encountered situation when also inability to rename juju application forces us actually to redeploy. Please see the following comment on the Github issue:

github.com/canonical/postgresql-operator

`promote-to-primary` action can break async-replication if primary unit on secondary cluster takes over sync role first

opened 01:13PM - 30 Apr 26 UTC

ggouzi

bug

On a dual-cluster setup with asynchronous replication (2+2), after `promote-to-p…rimary scope=unit`, the secondary is stuck in Replica and doesn't go to Sync Standby. Summary of the setup: | Member | IP address | Site | Patroni Status | | ----------- | ----------- | ----------- | ----------- | | postgresql-0 | 10.10.128.24 | Primary | Sync Standby (primary cluster) | | postgresql-1 | 10.10.128.23 | Primary | Leader (primary cluster) | | postgresql-0 | 10.10.118.24 | Secondary | Standby Leader (secondary cluster) | | postgresql-1 | 10.10.118.23 | Secondary | Replica (secondary cluster) | ## Steps to reproduce 1. On primary cluster, perform a `promote-to-primary` action to switch secondary to primary unit ``` juju run postgresql/0 -- promote-to-primary scope=unit ``` 2. Observe patronictl output ## Expected behavior ``` sudo patronictl -c /var/snap/charmed-postgresql/current/etc/patroni/patroni.yaml list + Cluster: postgresql (7633847608209757521) -+-----------+----+-----------+ | Member | Host | Role | State | TL | Lag in MB | +--------------+--------------+--------------+-----------+----+-----------+ | postgresql-0 | 10.52.128.24 | Leader | running | 4 | | | postgresql-1 | 10.52.128.23 | Sync Standby | streaming | 4 | 0 | +--------------+--------------+--------------+-----------+----+-----------+ ``` ## Actual behavior ``` sudo patronictl -c /var/snap/charmed-postgresql/current/etc/patroni/patroni.yaml list + Cluster: postgresql (7633847608209757521) --------+----+-----------+ | Member | Host | Role | State | TL | Lag in MB | +--------------+--------------+---------+-----------+----+-----------+ | postgresql-0 | 10.52.128.24 | Leader | running | 4 | | | postgresql-1 | 10.52.128.23 | Replica | streaming | 4 | 0 | +--------------+--------------+---------+-----------+----+-----------+ ``` ## Versions Operating system: Ubuntu 24.04 Juju CLI: 3.6.14 Juju agent: 3.6.14 Charm revision: 1047 LXD: 5.21/stable ## Log output Juju debug log: ## Additional context When the promote happens, we now have 2 nodes `postgresql-0` the pg_stat_replication table. First one in `sync` is the primary unit of the secondary cluster. Second one is the replica unit of the main cluster (the one we aimed to failover with the `promote-to-primary` action) ``` postgres=# SELECT application_name, client_addr, state, sync_state FROM pg_stat_replication; application_name | client_addr | state | sync_state ------------------+--------------+-----------+------------ postgresql-0 | 10.10.118.24 | streaming | sync postgresql-0 | 10.10.128.24 | streaming | potential ``` Workaround: - Adjust `synchronous_node_count` from `1` to `2`. This cannot be increased to more than 1 using `juju config`. ``` sudo charmed-postgresql.patronictl -c /var/snap/charmed-postgresql/current/etc/patroni/patroni.yaml edit-config ``` - Restart patroni on the main unit of the secondary cluster (10.10.118.24) ``` sudo snap start charmed-postgresql.patroni ``` Now the correct unit (10.10.128.24, new Leader) took over the `sync` state ``` postgres=# SELECT application_name, client_addr, state, sync_state FROM pg_stat_replication; application_name | client_addr | state | sync_state ------------------+--------------+-----------+------------ postgresql-0 | 10.10.128.24 | streaming | sync postgresql-1 | 10.10.118.23 | streaming | async (2 rows) ``` And patronictl returns proper config ``` sudo patronictl -c /var/snap/charmed-postgresql/current/etc/patroni/patroni.yaml list + Cluster: postgresql (7633847608209757521) -+-----------+----+-----------+ | Member | Host | Role | State | TL | Lag in MB | +--------------+--------------+--------------+-----------+----+-----------+ | postgresql-0 | 10.10.128.24 | Leader | running | 4 | | | postgresql-1 | 10.10.128.23 | Sync Standby | streaming | 4 | 0 | +--------------+--------------+--------------+-----------+----+-----------+ ```

I opened a seperate PF for that PF-6678