Migration strategy for charm relations

charm
1

I’m currently updating a charm to rename a relation in it and during its upgrade to the new version it failed with:

ERROR cannot deploy bundle:
cannot upgrade application "apache2" to charm "cs:~alejdg/apache2-0"
would break relation "nrpe:nrpe-external-master apache2:nrpe-external-master"

To work around that I:

  1. Remove the relation: juju remove-relation apache2 nrpe:nrpe-external;
  2. Upgrade the charm;
  3. Create a new relation using the new interface: juju add-relation apache2 nrpe:nrpe-external

That procedure works but it blocks upgrades since we have to remove the relation before proceeding.

As I plan to do the same thing for other charms, my question is: Is there a better way of migrating off from old relations?

Note that this is basically the same relation interface but with a different name.

Thanks

2

I thought your patch was allowing for both interface names for a bit with the same back-end code so that they could upgrade and then remove/add relations after the charm upgrade.

That being said, having a “deprecated/renaming” primitive in juju metadata.yaml relation processing would be a super helpful addition for the inclusive naming initiatives to be successful long term.

2 Likes
3

My patch for the NRPE charm allows that indeed but not my patch for apache2.

Keeping both interfaces would not really remove the terms but it would be a smoother approach for sure. However, at one point the old interface would be removed and whoever hasn’t upgraded the charm or upgraded it but did not change the relation would face the same problem.

With that, I agree that a “deprecated/renaming” primitive in juju metadata.yaml would be helpful also for any other charm rewriting that would require relations renaming.