unable to change relation scope on upgrade (e.g. scope: global -> scope: container)

Bug #1721289 reported by Dmitrii Shcherbakov
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
Low
Unassigned

Bug Description

A transition from global relation scope to container relation scope is not possible without removing a relation.

scope: global -> scope: container (in metadata.yaml)

https://code.launchpad.net/~dmitriis/telegraf-charm/+git/telegraf-charm/+merge/331171

https://code.launchpad.net/~dmitriis/telegraf-charm/+git/telegraf-charm/+merge/331171/comments/868801
"Upgrades fail with the scope change:

$ juju upgrade-charm --path ~/charms/repo/builds/telegraf telegraf
Added charm "local:xenial/telegraf-0" to the model.
ERROR cannot upgrade application "telegraf" to charm "local:xenial/telegraf-0": would break relation "telegraf:postgresql postgresql:db-admin"

Although it's not trivial to implement, what I would expect to see is:

* a relation scope has changed
* Juju does the remove-relation lifecycle at a unit level (-broken and -departed for units that are not in a primary-subordinate position) but not for the whole application
* all internal watchers and state for these relation structures previously needed are cleared out

A workaround is obviously to do `juju remove-relation ...` and `juju add-relation ...` but that's not always convenient.

summary: - unable to change relation scope on upgrade
+ unable to change relation scope on upgrade (e.g. scope: global -> scope:
+ container)
Revision history for this message
Ian Booth (wallyworld) wrote :

There's also other restrictions on upgrading a charm, for example you can't rename a peer relation. This sort of thing was outside the original implementation design, and yes it will be a lot of work to implement. How much of an issue is it in practice? Does it materially affect the ability to satisfy our customer requirements or fulfil field operational requirements?

Revision history for this message
Dmitrii Shcherbakov (dmitriis) wrote :

It's not critical as of now as far as I see it.

I think the effort of implementing this vs benefit is quite low for now.

It might be worthwhile to leave it as a wishlist with low priority in my view. At least this case will be documented.

Having this ability would allow one to handle longer charm maintenance without the need to go through a per-app remove-relation -> update-charm -> add-relation lifecycle.

Normally we add new relations though and do not change semantics of already existing ones at that level.

John A Meinel (jameinel)
Changed in juju:
status: New → Triaged
importance: Undecided → Low
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers