operator: Add Relation.broken to allow querying if a relation is broken (breaking)

It’s sometimes good to be able to query for relations and then determine if the relation you’re looking at is broken (due to the current event being a relation-broken event for the relation in question, or while handling deferred events before that event). So it would be good to add a Relation.broken boolean attribute (or perhaps its inverse, Relation.active?) that ops sets based on the relation data and incoming event.

This is to solve the issue I’ve been discussing with @carlcsaposs-canonical with the mysql-router-k8s charm using a “stateless status setting” approach, but having to pass the current event down to all their get-status functions. It’d be conceptually simpler (and perhaps better in the case of deferred events?) to just be able to query relation.broken.

So this should probably be done as part of or shortly after the multi-status work (spec OP033).

About this issue

Original URL
State: closed
Created a year ago
Comments: 21 (15 by maintainers)

Commits related to this issue

feat: add Relation.active, exclude inactive relations from Model.relations (#1091) This PR allows Charmers to easily check whether a relation is broken during a `relation-broken` event (and also fra... — committed to canonical/operator by tonyandrewmeyer 6 months ago

Most upvoted comments

That’s a reasonable idea, @sed-i, thanks. I intend to discuss this with John M a couple of others next week, to see if we can finalize which approach we take.

benhoyt on Jun 29, 2023

I discussed this with @jameinel today, and we lean towards excluding the broken relation from model.relations["foo"] during relation-broken (but not from prior relation-departed events). This makes more sense, and is what charmers expect.

In terms of backwards-compatibility and whether this would be a safe change to make, I’ve done a cursory look through a bunch of charms I have downloaded, and where they iterate over model.relations it looks like it’s in contexts where the broken relation shouldn’t be included anyway. So I think it probably would be safe to do this.

One tricky thing is what model.get_relation() would return, and what the .relation attribute of the RelationBrokenEvent should be in the relation-broken hook. If we just made the change to model.relations to exclude the broken relation, get_relation() would also return None and the RelationBrokenEvent.relation would be None. (This would happen as it’s no longer in model.relations["foo"], and get_relation uses that via RelationMapping._get_unique.) I’m not sure that’s a good idea.

Ideally we’d make the change to Juju’s relation-list hook tool. However, ops would still have to exclude it manually for older versions of Juju.

As next steps, @wallyworld said he’d bring this up at the next charm guild meeting next week to try to discuss the Juju aspects of this then.

benhoyt on Jul 6, 2023